How best to extend Entity Framework generated POCO objects whilst maintaining the relationships

I'm working on a project where I've created a core DAL / BLL with the Entity Framework and generating POCO objects. I've created partial classes for the POCO's to contain the core functionality that I want to implement on these base business objects.

The solution is going to be for multiple clients all with slightly different ways of implementing their business logic. I'd like to be able to extend some of the POCO objects to add additional / change current functionality. I want to keep this separate from their core functionality which as I said is defined in the partials.

The problem I have is that if I create an object which extends a POCO object I can only maintain the relationship between the extended object and the original POCO objects it relates too. I need to somehow be able to define the relationship between extended POCO objects.

An example would be if I had a Customers POCO which contained a list of Orders which were also POCOs. Say for some reason I need to customise the Customer class so I create a CustomCustomer class which extends the functionality of Customer. Then for some reason I need to customise the Ord开发者_运维问答er class so I create a CustomOrder class which extends the functionality of Order. How do I maintain the relationship between the CustomCustomer and CustomOrders.

I initially thought that the Decorator pattern may be able to help me here but when I started to practically implement it, it seemed like a fair bit of work and I just wanted to see if I was missing something obvious before I continued.

---

You have two approaches here, depending on what you need:

If your CustomCustomer class need to use a CustomOrder, but not through custom methods (meaning that you can use it referencing just the Order base type), you don't need to keep those new references, Entity Framework take care of that for you, as long you configure the inheritance hierarchy.

It will load the Orders list, but some of them will actualy be CustomOrder, but on a Order list.

On the other hand, if you actually need to use those CustomOrder, typed as CustomOrder on the CustomCustomer, create a property on CustomCustomer filtering all the Orders except the custom ones:

public IEnumerable<CustomOrder> CustomOrders
{
    get
    {
        return base.Orders
            // We check the BaseType here because EF creates a derived class of our classes. 
            .Where(o => o.GetType().BaseType == typeof(CustomOrder))
            .Select(o => o as CustomOrder);
    }
}

Note that, even on the second approach, you need the inheritance hierarchy configured in EF for this to work.

If none of this work for you, go to the hard route: put CustomCustomerId on the CustomOrder, have a separate list on CustomCustomer, and be ready to live with the fact that if you get all orders witch contain CustomerId = 1, you may not have ACTUALLY got all of them...

---

Your POCO's are not business objects. They're data objects. If you want to implement business objects, you should create buisness versions of these objects, then copy the data between the data and business objects as needed. Tools like AutoMapper help with that.