Putting the M in MVC – Part I

Tuesday, March 31, 2009

Model is one of those overloaded words in software. Just saying the word model can produce a wide range of expectations depending on the context of the conversation. There are software process models, business process models, maturity models, domain models, security models, life cycle models – the list goes on an on. Nerds love abstractions, so it’s not surprising that we have so many models to choose from.

Let’s talk about a specific model – the model in model-view-controller. What is it? How do you build one? These are the types of questions a developer will ask when working with the ASP.NET MVC framework. As Simone Tokumine points out in his post “.NET MVC vs Ruby on Rails”, there isn’t any direct and specific guidance from Microsoft:

.NET MVC is actually .NET VC. It is an attempt to replicate the Actionpack components of Rails. There is nothing included aside from a folder labeled “Models” to help you with your persistence later and domain modeling.

The scenario isn’t unique to the MVC framework. Microsoft has a long history of leaving the model of an application open to interpretation, and this stance is both a blessing and a curse. A blessing because we can build models to meet the distinctive needs of every application imaginable, and we can use a variety of tools, frameworks, patterns, and methodologies to build those models. However, the curse is that many of us never look outside of the System.Data namespace. Populated DataSets and data readers are the models in many applications, even when they aren’t the best fit.

Enter the Entity

One reason that DataSets dominate .NET development is because they are featured in the majority of samples and documentation, particularly for ASP.NET Web Forms. In contrast, ASP.NET MVC samples typically feature business objects as models. Even the new MSDN documentation says:

Model objects are the parts of the application that implement the domain logic, also known as business logic.

It’s not surprising then, to see many people using domain objects, business objects, and entities produced by LINQ to SQL or the Entity Framework as model objects.

Do business objects and entities really make the best models?

This is the question I'd like to explore by sharing my opinion and gathering feedback over the course of two more blog posts...

Dominic Pettifer Tuesday, March 31, 2009
I'm currently using a Service Layer for the Model my MVC application, the Controller communicates with the Service layer, and the Service layer communicates with a Repository (all behind interfaces).

Thing is, I'm getting the repository to return view specific objects, rather the the Data entiry objects themselves. eg. rather than return a Blog NHibernare object, it returns a BlogDetailView object, with all the necessary data prepopulated.

I'm not sure this is the best approach but it seems to work OK. Which is one of the main problems with the examples and documentation given on ASP.NET MVC, they don't seem to flesh out the Model part fully, the examples they give are highly simplistic and don't map very well to real world applications. Some guidance on this would be much welcomed!
scott Tuesday, March 31, 2009
@Dominic - Great! I'll offer my thoughts.
Comments are closed.
Pluralsight Courses
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!