Business logic in Entity Framework POCOs using partial classes?

I have business logic that could either sit in a business logic/service layer or be added to new members of an extended domain class (EF T4 generated POCO) that e开发者_Go百科xploits the partial class feature.

So I could have:

a) bool OrderBusiness.OrderCanBeCancelledOnline(Order order) .. or (IOrder order)

or

b) bool order.CanBeCancelledOnline() .. i.e. it is the order itself knows whether or not it can be cancelled.

For me option b) is more OO. However option a) allows more complex logic to be applied e.g. using other domain objects or services.

At the moment I have a mix of both and this doesn't seem elegant.

Any guidance on this would be much appreciated!

The key thing about OO for me is that you tell objects to do things for you. You don't pull attributes out and make the decisions yourself (in a helper class or other).

So I agree with your assertion about option b). Since you require additional logic, there's no harm in performing an operation on the object whilst passing references to additional helper objects such that they collaborate. Whether you do this at the time of the operation itself, or pre-populate your order object with those collaborating entities is very much dependent upon your current situation.

You can also use extension methods to the POCO's to wrap your bll methods. So you can keep using your current bll's. in c# something like:

public static class OrderBusiness <- everything must be static, class and method
{
  public static bool CanBeCancelledOnline(this Order order) <- notice the 'this'
  {
    logic ...

And now you can do order.CanBeCancelledOnline()

This is likely to depend on the complexity of your application and does require some judgement that comes with experience. The short answer is that if your project is anything more than a pretty simple one then you are best off putting your logic in the domain classes.

The longer answer:

If you place your logic within a service layer you are affectively following the transaction script pattern, and ending up with an anaemic domain model. This can be a valid route, but it generally works best with simple and small projects. The problem is that the transaction script layer (your service layer) becomes more complicated to maintain as it grows.

So the alternative is to create a rich domain model that contains the logic within it. Keeping logic together with the class it applies to is a key part of good OO design, and in a complex project pretty essential. It usually requires a bit more thought and effort initially, which is why for very simple projects people sometimes use the transaction script pattern.

If you are unsure about which to go with it is not normally a too difficult job to refactor your logic to move it from your service layer to the domain, but you need to make the call early enough that the job is not too large.

Contrary to one of the answers, using POCO classes does not mean you can't have business logic in your domain classes. POCO is about not applying framework specific structures to your domain classes, such as methods and interfaces specific to a particular ORM. A class with some functions to apply business logic is clearly still a Plain-Old-CLR-Object.

A common question, and one that is partially subjective.

IMO, you should go with Option A.

POCO's should be exactly that, "plain-old-CLR" objects. If you start applying business logic to them, they cease to be POCO's. :)

You can certainly put your business logic in the same assembly as your POCO's, just don't add methods directly to them, create helper classes to facilitate business rules. The only thing your POCO's should have is properties mapping to your domain model.

Really depends on how complex your business rules are. In our application, the busines rules are very straightforward, so we use Option A.

But if your business rules start to get messy, consider using the Specification Pattern.