Business logic in Entity Framework POCOs using partial classes?

Question

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 exploits 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!

Answer 1

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.

Answer 2

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.