Will you put the model part in asp.net mvc into a different library/assembly?

Question

Will you put the model part in asp.net mvc into a different library/assembly?

Edit

Or should we put put the model part in asp.net mvc into a different library/assembly?

Answer 1

I do :-) works out just fine

Answer 2

I do too so that I can keep all my nHibernate stuff separate.

Answer 3

A related question can be found here: Best place to place Domain objects in an ASP.NET MVC App?

Answer 4

I have got my domain models in separate assemblies. The models folder in the MVC project contains only view models.

Answer 5

My personal opinion is that the answer would be yes - different assembly. I would go with both a separate project, separate namespace, and a separate assembly. However, I decided to consult several of the readily available ASP.NET MVC reference apps to see how they did it. The results:

• Car TrackR - Same project (under Models folder), same assembly, different namespace
• FlickrXplorer - Same project (under Models folder), same assembly, different namespace
• Kigg - Different project (under Domain Objects), different assembly, different namespace
• Mvc Store Front - Different project (under Kona.Model), different assembly, different namespace
• Nerd Dinner - Same project (under Models folder), same assembly, different namespace
• Oxite - Different project (under Oxite/Models), different assembly, different namespace

Looks like the split is about 50% / 50%. Oxite is the only application meant to be redistributed and run so I'm partial to its structure. However, my absolute preference is to structure things similar to the way that the Mvc Store Front is structured.

Answer 6

I put the domain models in a different assembly and namespace.

I don't always stick with one application type and having my domain models in a separate assembly makes reuse much easier. While I may see the primary use as a web-based MVC application I may find that I need a desktop version or a iPhone or Windows Mobile application that uses the same domain models so it makes sense to have them separated.

I will however typically still have models in the MVC applications. I tend to use one class for each View and I keep those models in the MVC app itself.