How can I extend the Model in ASP.NET MVC and Entity Framework?

views:

232

answers:

+2 Q:

How can I extend the Model in ASP.NET MVC and Entity Framework?

In my first ASP.NET MVC applications, the model was a simple O/R mapping between a table and the classes, managed by the Entity Framework.

Now I would like to add some meat to this skeleton, and introduce business methods for the generated classes. What is the recommended approch to this in ASP.NET MVC (with Entity Framework)? My favorite would be solution which also can be used in a service layer, with no ASP.NET MVC references, so that the same domain logic also could be reused in a desktop client.

Technically, I think it should be possible to extend the generated classes in a way which preserves the additional business logic even if the O/R classes need to be refreshed. (This is more a question related to the Entity Framework however.)

Edit: Many thanks for the contributions, and the information about the next version of Entity Framework (4.0). Building two sets of classes, one auto-generated to represent the data in the persistency layer and one for the actual business logic sounds interesting.

+4 A:

Within MVC.Net, the model is the least clearly defined part. In my opinion, it's basically the rest of your application (i.e. anything not related to the View or the Controller). The O/R Mapping part of your application should probably be outside of the "Model" also, as this is more of a data layer. The Model, should really deal in business objects and create views of your data to pass to the View.

There are lots of differing opinions on this, but I think it's best not to think of MVC.Net as traditional MVC Architecture.

Jimmeh 2009-08-19 12:58:57

Do I understand correctly that you suggest to create the business logic using a separate hierarchy of 'business objects' which are then mapped to 'data objects' provided by the O/R framework?

mjustin 2009-08-19 13:06:40

That is a way of doing it. I think there are lots of ways. I do think the O/R Mapping layer should be separate to business logic, though.

Jimmeh 2009-08-19 13:13:42

+1. Although you *can* extend generated entity types, it is a far better design to keep your business logic completely independent of the EF, and then project your entity query results onto BL types via LINQ.

Craig Stuntz 2009-08-19 14:11:12

The EF v1.0 limitation on POCO is a problem here, and it will be addressed in the upcoming v4.0.

J.W. 2009-08-19 19:11:54

J.W., I completely disagree. No POCOs are a limitation if you must cram your business logic into entities. If you make your business logic entirely separate, as Jimmeh suggests, then you can project your entities onto business objects with LINQ. BOs are *real* POCOs, not proxy bases with 100% of members declared public virtual.

Craig Stuntz 2009-08-19 19:55:32

Craig, I see and agree your point here. If I understand correctly, you want to create another BO layer on top of those entity classes created by Entity Framework. To me, it will be a more clear approach if I can get POCO directly out of entity framework, so I don't have to use another layer.

J.W. 2009-08-19 20:52:20

Yes, J.W., that's right. Using a separate business layer is separation of concerns. Your entity model maps relational data into object space; your BOs are your app logic. The middle layer allows them to evolve independently. ORMs with broken/limited/nonexistant LINQ implementations are forced to use POCOs, though.

Craig Stuntz 2009-08-20 01:53:38

Craig, I am not convinced: if the business layer is separated from the persistence layer, the business layer has to keep track of its object manipulations (units of work) too, and then transfer these changes down to the persistence layer, which then performs the same operations to apply the changes to the DB. I understand that decoupling has advantages, but how high is the price for it?

mjustin 2009-11-07 11:30:11

Not only meat but also some clothes and a style could be added to this project to make it seem chic. It depends on the time you have for the project. If you have time, I could suggest you to get a look to TDD and the frameworks that could be used with TDD such as Castle, NUnit, Moq etc.

As you mentioned a service layer is a must for any project but with these kinds of frameworks you could design your architecture more robust.

yapiskan 2009-08-19 13:03:01

Abstract your Business Layer out into another project, then pass an instance of it onto your mvc controller using something like structure map. You can then call this Business Layer from your controller to retrieve your business entities (Model) and pass them on to the UI. This will allow you to resuse your Business Layer in your desktop application.

StarSignLeo 2009-08-19 13:05:25

+1 A:

If you are using EF v1.0 right now, the Entity Framework is very intrusive into your application, which means that you cannot create POCO very easily. The way you can extend your model is by using the partial class. So when you refresh your model, the partial class you did will still be valid. The Entity Framework team realizes this is a problem , and have improved this in next version (EF V4.0).

NHibernate is much more friendly and allow you easily extend your business logic.

I really think this blog post by Jeremy D. Miller is very good at pointing out the problem.

J.W. 2009-08-19 19:10:23

NHibernate also supports lazy loading and some kinds of class inheritance. I guess that EF 4.0 and NHibernate will be strong competitors, which can be good for both of them - and the users :)

mjustin 2009-08-19 20:30:39

ansaurus

tags:

views:

answers:

How can I extend the Model in ASP.NET MVC and Entity Framework?

related questions