Question

Possible Duplicate:
Using Entity Framework entities as business objects?

I’m looking into using Entity Framework as an ORM, but after doing lots of reading I’m really confused as to where EF objects fit exactly.

I was under the impression that the whole point of an ORM was to remove the drudgery and complication of mapping your object to a relational database. You load your DB and get a bunch of objects like magic. CRUD stuff all gets done against objects. If the DB changes you change the mapping but your objects stay the same.

This would imply that you are going to use these objects throughout the system, and that they will have behaviour. They are business objects. This makes sense to me, and indeed MS tells you how to add behaviour

However, I’ve been reading lots of people saying that your should never use EF objects as your business objects as they are concerned with persistence of data only, and would couple your business objects with EF. They suggest using EF as an abstraction of the data layer, and mapping them to real business objects.

This seems pointless to me. Why do I need yet ANOTHER abstraction layer when I still end up mapping to my business objects? If I have to map EF properties, I might as well map DB columns!

I thought the whole point of an ORM was to automate the mapping and act as an abstraction over the backing store? Am I missing something?

EDIT: By behaviour I mean business logic. Validation, calculated properties, business methods etc.

Answer 1

If the DB changes you change the mapping but your objects stay the same.

No. Db changes will also change the mapped entity classes. But that does not mean that these classes can’t be used for business logic. If you use EF out of the box it will create entity classes as partial classes, so you are invited to add your own code in a way that it is not overwritten by generated code.

people saying that (…) [EF objects] are concerned with persistence of data only

I don’t think so. They may be equipped to be persisted to and populated from a data store (as they are when working database-first), but it is not their concern. We should ignore this added behaviour and not use it in business logic (is my opinion). The objects are not persistence-ignorant, the business logic should be.

Having said this, I use entity classes for business logic all the time. But I’m not a fan of pure OO any more, in the sense of closely cooperating objects with meticulously separated responsibilities. For two reasons:

1. Most applications involve some sort of business layer and a view layer with view models, glued together by a controller layer and communicating over a boundary that requires serialization. So invoking behaviour of domain classes directly is often not an option. Therefore, I tend to program more and more BL in service classes or façades that communicate through DTO’s and less in domain models that are addressed directly from other layers. These service methods tend to be perfect places for business logic. So most of the time, I extend EF classes with logic that involves data within the class itself and does not require any cooperation with other EF classes. This also prevents lazy loading exceptions and n+1 problems. I could show many examples where I happily moved from domain logic to BL in service methods, but that’s a bit beyond the scope of this question.

   Likewise, I’m not a fan of using OnPropertyChanging/Changed as one of the MS links describes. I’ve done it and it is spaghetti. It can be useful in view models, e.g. to respond to user input, but in domain classes setting a property should be that: setting a property. No added behaviour that gets forgotten and one day bites you.

2. The advance of a (stateless) functional programming paradigm, which was encouraged by Linq and other .Net language constructs.

So I see my domain models moving closer to anemic domain models, although never really getting there. I’ve tried to give some reasons why this can be perfectly sensible nowadays.