Why not to use Classes that generated by EF in large Projects?_问答_开发者

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 ???

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.

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.

One needs to be extra careful when exposing EF generated classes all the way to Javascript.

Firstly, you may be exposing way too many fields than you need. This will increase payload and make it easy for attackers to guess your database schema.

Secondly, if you also let the MVC Model Binder to deserialize HTTP (either via Request Body, URL, or any means) data into EF models and then save it directly to the database, you are at great risk. Anyone should be able to temper the HTTP requests to send you a JSON object that would overwrite fields that you would not expect. Think about this shopping cart object:

{cartItems: [{itemId:1, quantity:100, product:{ productId:23, price:0 }}]}

If I could pass in a product with price 0 and a valid productId, EF will override the price of the specified product in your database.

If your project is large, I recommend you to follow Domain Driven Development. Each domain class comprises of a number of components: EF entity properties, property injection for behaviors (formatting data, parsing, converting, copying, validating, configuration).

If you follow Single Responsibility Principle, each class should have only 1 responsibility. EF model classes should be for storing data and communicating with EF infrastructure to generate runtime SQL. Other classes will take care of formatting, conversion, validation and transferring.

When the number of types increases, you need to centralize or organize them using Facade pattern. These Facades are domain specific types. So, if you start from generating EF models, then build the supporting types (formatters, validators, ...), and finally create domain types, you will not have greater collaboration and distribution ability as you could have gained by going in reverse. Build your domain types first, build mocks and unit tests, then share it with your peers to let them connect the domain object's functions with EF models. That's how you can do Domain Driven Development.