Best practices for project organization with ASP.NET MVC

Question

I recently downloaded Rob Conery's excellent ASP.NET Storefront reference application and am finding it incredibly instructive. One question that comes to mind is where one should place the Model classes (and the Data classes upon which they depend). The MVC project template creates a Model folder. But it seems to me that I would be better served breaking the model out into a separate project assembly so that it can be re-used by other potential applications (e.g. management tools related to the website's application domain)?

I'm curious to get people's opinions.

Answer 1

It really depends on the size of the project. There's no inherent value in having a separate "models" assembly, as you can unit test a Web Application project (including MVC projects).

Answer 2

I would agree. Unless the application is only ever going to be the single web application, I would break it out into a separate project. Typically I will have a web application front end that uses one or more windows services to perform recurring, automated tasks (submitting charges, sending notifications, etc) and one or more console application tools to provision the application user base from our enterprise directory -- my apps are typically intranet apps that may apply only to subsets of our entire user population. Having the models (data layer) in a separate project allows me to easily share it with all other applications.

Answer 3

If you models are Domain Transfer Objects, then having them in a sepearate assembly will allow you to reuse them. If your app is a simple MVC app, and that's all there is to it, or you're just doing it to unit test, it's not needed. Otherwise you could:

• Have you web service layer use the models assembly to pass the model objects to the mvc app for use in your application. This would be needed if you practice not allowing web apps to have direct access to the database. In that case you might have a mvc that calls a web service to authenticate and pull the data.

• You intend building other applications using the same models, like the management tools you mentioned.

I hope that helps. On a side note, you might want to put your "common" pieces in your own framework, which would include "models" (entities, domain objects, whatever name you like).

Answer 4

Separate assemblies != loose coupling.

Answer 5

I like to have seperate projects for my model, data access and business logic. I also have interfaces at each layer. This makes tests with mocks simple to implement, keeps my code organized and keeps my controllers light. If I placed all of the layers in the models folder, it wouldn't feel organized enough for me(just a personality thing). I also like to have the option to expose web services for my apps, so this makes all of the same logic, models and data access available for those services.