0

We are building an ASP MVC3 application, where we are building the service layer and Entity model. A third party is building Views/Controllers.

Now the tricky bit is the Model. Where should it go?

My opinion is the MVC web application will just have View and controller. Our service library will have business logic and EF. But I think we should not expose EF entities directly to the web application. (or should we? ) Instead we should look at the views and create view model classes for each views. This might require creating multiple view model classes for each view.

Can anyone provide their opinion on if this is right design? If so, where should view models reside? should we create another library just for view models?

gunnerz
  • 1,898
  • 5
  • 24
  • 39
  • This might help you : http://stackoverflow.com/questions/11074283/model-meaning-in-mvc/11074365#11074365 – StuartLC Jun 22 '12 at 15:44

1 Answers1

2

I would suggest making your models as POCO objects with CRUD functionality- you shouldn't expose the EF entities. This way your service library can be reused in other applications or interfaces if needed.

If the POCO objects you provide won't work directly as view models, then it's up to the team writing the controller to create a view model from your service objects (POCOs). That would probably (hopefully) be a very simple view model, using your POCOs as properties (maybe a view model is a list of one of your POCOs, or a combination of a couple different POCOs).

That's just my two cents...

The Jonas Persson
  • 1,726
  • 1
  • 17
  • 36
  • Thanks Jonas. I am assuming you mean we create one POCO class for each entity? Will that not just mean we are copying the entity structure into another class? – gunnerz Jun 22 '12 at 16:07
  • It would be one POCO for each entity only if you feel that the entities best reflect the data you want to model. It might be that you don't want to expose all the entities. Also, by not exposing the entities you get full control over how the CRUD works. If you don't want anyone to really delete an object, you can set a flag instead, etc. If you are using EF 4.1 there are extensions to download that create the POCO for you, then all you need to do is the CRUD functionality. ([More thoughts on POCO](http://stackoverflow.com/questions/2635953/what-are-the-big-advantages-to-have-poco-with-orm)) – The Jonas Persson Jun 22 '12 at 16:33