How should I namespace my models in ASP.NET MVC? Confused about Nerd Dinner.

Question

I am learning ASP.NET MVC and I like it. However, I am very confused about the right approach to namespacing my models.

While dissecting the NerdDinner sample app I noticed that everything in the Models folder belongs to the Models namespace. The data mapping classes, repositories, error rule management, etc., belong to the same namespacing level.

I understand that this folder was inspired by frameworks like Rails and friends, and that it is required to justify the M in the MVC title but; doesn't an automatic Model namespace destroy any chances of writing business logic that is both detachable and portable across different systems and implementations?

Should I namespace my business logic below this Model namespace or should I ignore it completely and classify my classes in a more framework independent manner?

Are there any complex and good ASP.NET MVC sample apps out there that would demonstrate this?

Answer 1

I would classify your classes in the way that makes the most sense to you, I suspect they used that namespace in the Nerd Dinner sample app because from a learning stand-point it is nice for a developer to always see that they are in the Model portion of the application.

Personally I don't put anything in the Model folder and create separate projects for my entities (App.Domain) and for domain services (App.Services). I also create .Tests projects for both projects.

Answer 2

My dev-senses told me that we should be refactoring our data models into another project altogether. Some have even gone so far as to create your business entities in yet another project, and have them constituted from the Linq-Sql classes.

I figured Scott and Co. would have gone the way of at least separating the data model from the presentation tier. We all know the benefits of separation of concerns, but it's puzzling me with the way they kept the data model within the MVC app.

Any more suggestions on a more layered way to go?