Home > Blogs > How and Where to Create Entity Class When ASP.NET MVC and Entity Framework Used

How and Where to Create Entity Class When ASP.NET MVC and Entity Framework Used

Thought about writing on topic as someone asked me this Question: “How and where to create Entity Class when we’re using both ASP.NET MVC and Entity Framework in the same project?”. Really, it’s been a topic discussed in the .NET Solutions Architects circle a lot. Let me explain the scenario why everyone gets confused when these technologies come into picture together, in the same project.

Let’s say we’re going to have multi-layered project architecture like UI Layer using ASP.NET MVC, Service Layer using Web APIs, Business Layer, Business Entities, Data Layer with Entity Framework plus other utility layers such as Exception Utility, etc.

The MVC project has got Model classes, which are used to derive Views. Most of the time, I would not say ALWAYS, the Model classes represent the entity like Customer, Employee, Transaction, Sales Invoice, etc.

Then we go and design our entity models in the Business Entities layer. These entity classes also represent same entity as MVC Model classes. There is a greater similarity between classes into these two layers.

Then comes our Service Layer like WCF or Web APIs. Again, either these layers have separate classes representing same entities as MVC or BE layers, or they use BEs classes as Data Models.

At last, the Entity Framework being used in the Data Layer. It also auto generates the classes which actually represent the database tables, and look very similar to the BE classes. So, we see now that almost every layer has got its own class representing the same entity.

The question is: “Shall we create entity classes in all the layers separately or can we have a single layer having those classes at one place and use in all other layers or any combination option?” It’s very difficult to take a decision up as every approach have got its pros and cons. I’m in support of below three approaches based on the architectural decisions:

APPROACH 1:

Create all entity classes at one place, in one layer i.e. Business Entities. Our MVC’s View, Service Layer and the Entity Framework in the Data Layer can use it from there. Of course, there is very less hassle to maintain the Business Entities but there are other problems attached with this approach. If any layer requirement changes for example database table schema changes, or MVC UI changes, we need to change the class over and over again. And, every layer will have to accept those change whether it’s going to use those changes or not. It’s kind of very tight coupling in the project, which every solutions architect avoids.

APPROACH 2:

Keep the MVC Model classes separate, but the Entity Framework and other layers should use classes from the Business Entities layer. The UI layer is always prone to changes, hence changing the MVC Model classes frequently. But, then we need not to change the Business Entities layer and, hence no impact on the other layer. The maintenance becomes easier. This approach gives us flexibility and makes other layers less independent on each other i.e. loose coupling.

APPROACH 3:

Allow all layers to have their own model or Entity Class. MVC Model should have its own class, Entity Framework should have its own classes, which other layers might use classes from the Business Entities layer. This is the most flexible approach, where there is no or less degree of dependency on each other. If UI changes, MVC needs to change the class in Models, database table schema changes, the Entity Framework needs to change the classes in Data Layer and if business requirement changes, the Business Entity needs to change classes. This approach provides us higher level of flexibility. Though, people might argue that it will bring down the performance of the application as we need to exchange data in all these layer. Yes! I agree. Maintenance comes at a cost. However, I think it will not affect the performance drastically, little is acceptable.

If I have to make a decision, I would go with the Approach 3. Why??? 🙂 Now, you know better.

Hope, this blog helps you out to decide where to create Entity class when using MVC and Entity Framework together in the same project. Please rate this blog and let me know you feedback/suggestions.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: