Should you use a partial class across projects

Question

Ok,

So, 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 to add method 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
  }
}

The Question is:

Is this 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.

Answer 1

You can't write a partial class across projects. A partial class is a compile-time-only piece of syntactic sugar - the whole type ends up in a single assembly, i.e. one project.

(Your original DAL file would have to declare the class to be partial as well, by the way.)

Answer 2

Partial classes have to exist in the same assembly. Otherwise, how would the compiler decide where to merge the partial classes to?

Answer 3

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.

Answer 4

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:

Northind.DAL (prj)
-NorthindDataContext (EntityNamespace set to "Northwind.BLL")
--Product() (Entity, partial class auto-generated)
--Category() (Entity, partial class auto-generated)
--Supplier() (Entity, partial class auto-generated)

Northind.BLL (prj)
-Product() : IMyCustomEnityInterface, BaseEntity (override OnValidate(), etc)
-Category() : IMyCustomEnityInterface, BaseEntity (override OnValidate(), etc)
-Supplier() : IMyCustomEnityInterface, BaseEntity (override OnValidate(), etc)

Unfortunately, we can not do this... actually I'd love to know what the recommended way of splitting up layers/tiers when using LINQ.

Answer 5

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:

• The first thing that springs to mind is inheritance. It's not necessarily the best solution always, but you may not have a choice since you may need to be able to have your objects be able to be treated like the base class.
• Composition is also a good choice (that is, wrapping the class in another class). This gives you a little bit nicer decoupling from your DAL, but can be tedious to implement.
• If you really just need to add a method or two onto an existing class, you might also consider using an extension method, but these can quickly create spaghetti code if you use them too much.