I have a class library with all my database logic. My DAL/BLL.
I have a few web projects which will use the same database and classes, so I thought it was a good idea to abstract the data layer into its own project.
However, when it comes to adding functionality to classes for certain projects I want to add methods to certain classes.
For example, my data layer has Product and SomeItem objects:
// Data Access Layer project
namespace DAL {
public class Product {
//implementation here
}
public class SomeItem {
//implementation here
}
}
In one project I want to add an interface that is used by different content items, so I have a class called:
// This is in Web Project
namespace DAL {
public partial class Product : ICustomBehaviour {
#region ICustomBehaviour Implementation
TheSharedMethod();
#endregion
}
}
Is it a good idea to write a partial class in a separate project (creating a dependency) using the same namespace? If it's a bad idea, how can I get this type of functionality to work?
It doesn't seem to want to merge them at compile time, so I'm not sure what I'm doing wrong.
Partial classes have to exist in the same assembly. Otherwise, how would the compiler decide where to merge the partial classes to?
I agree with Jon Skeet's answer.
I don't think it would be a good choice to approach an issue like this anyway. There are good design patterns out there already that demonstrate the best way to split your tiers/layers of code, and this is just a little syntactic sugar so that Microsoft could make the WinForms/WebForms designer files separate and prevent people from breaking them.
No.You cant write partial classes in different projects.Because at a time compiler gets a single project for compilation and so scans for list of classes,methods,fields etc in that project only.So if you have some parts of the partial class in other projects,compiler cant find those.
While I agree with you Neil when it comes to pre-linq development, I also wish I could be able to do this in order to split up bussiness logic from partial classes generated by Linq2SQL designer. For example:
Unfortunately, we can not do this... actually I'd love to know what the recommended way of splitting up layers/tiers when using LINQ.
I can't answer your question about the best way to organize your layers, but I can try to answer your question about how best to emulate partial classes.
Here are a few thoughts:
Using Visual Studio 2015 and later it is possible to split partial classes across projects: use shared projects (see also this MSDN blog).
For my situation I required the following:
Due to limitations of the installer this setup has to be self contained. It cannot reference any assemblies beyond the .NET framework. The setup should insert some enum constants into tables, so ideally it should reference the class library.
The setup can import a Shared Project.
The following example demonstrates how partial classes and shared projects allow splitting classes over different projects.
In Class Library, Address.cs:
Class Library is a normal Visual Studio Class Library. It imports the SharedProject, beyond that its .csproj contains nothing special:
Address.Direction
is implemented in the SharedProject:SharedProject.shproj is:
And its .projitems is:
The regular client uses
Address
includingAddress.Direction
:The regular client csproj references the Class Library and not SharedProject:
The DbSetup uses only the enums:
The DbSetup.csproj does not reference Class Library; it only imports SharedProject:
To conclude:
Yes, use Visual Studio's Shared Projects.
Often not (see the other answers); in some situations and if you know what you are doing it can be handy.