views:

54

answers:

2

Hi everyone.

I'm going to use Entity Framework 4 in sort of big project.

And i know that many professional programmers advice to depend on my business classes instead of EF Model classes.

Actually there is sound inside my brain tell me "Don't depend on that generated classes !. Just make your hand dirty with your stuff don't let someone else do that for you. !!"

But actually i don't know where is the problem to use these generated classes in such a big "Enterprise" projects.

So please make me understand why ???

+4  A: 

There's absolutely nothing wrong using the EF-generated classes. That's what they're there for.

But if you misapply the technology, you are in for a lot of problems. For example, a lot of beginners will try to use those EF-generated classes for everything. They'll take the classes, marshal them across an AppDomain boundary with WCF or Remoting, and maybe they'll bind to them on their front ends. That might work for a quick and dirty CRUD-based application, but it's not going to fly for anything with any real size.

Why not? Because EF-generated classes are modeled in the data "domain" of your application, not the presentation "domain". What a user might want to interact with is often not an object which is 1:1 with a table in your database. For example, a user might have a grid of "Products". Inside this grid would be the total dollars sold of the product, along with certain indicative data about the product. While the indicative data (Name, Size, etc) will probably come right off the Product table and therefore the generated Product class from EF, the aggregate data (total dollars sold) is an aggregate value.

What we typically do is use the EF-generated classes in our service, and then use the service to translate the EF classes into ViewModels which we then bind to on our front ends using WPF (or whatever your favorite technology is). That gives us the separation of concerns we're looking for.

Dave Markle
Thank u for good explanation. But I'm not talking about using ViewModel. I'm talking about creating new Layer "Or tire" between ViewModel and EF Model "My Business Model layer". is this sort of separation good or it's just an extra work.
Wahid Bitar
It's almost always just extra work. Yes, you can and perhaps should create another layer in your classes which your services use to create your ViewModels/etc, but creating a whole new tier where you have to marshal another type of object across an AppDomain is almost always a mistake -- one that you often pay dearly for when it comes to performance and scalability.
Dave Markle
I agree with Dave. I've only used EF on small projects so far, but I have yet to find the need for a separate Business Object layer; the EF entities have always been flexible enough to act as BOs.
Stephen Cleary
+1  A: 

In addition to Dave's good answer, I want to mention another important drawback of using the generated classes : they are derived from a common base class (EntityObject). If you have an existing domain model with its own inheritance hierarchy, it can be a problem because multiple inheritance is not supported in .NET.

Thomas Levesque