Factory Class for ViewModels – Is It Necessary?

asp.net-mvcdesign

A colleague of mine suggested using a factory class for creating viewmodel objects in our ASP.NET MVC solutions. The idea being that it can help with the design, and maintainability, of the way viewmodels are built in our apps.

I wanted to find out if anyone else has experience of this. I've done some research and found very little on this practise.

Currently we create viewmodel objects at the controller level eg

public ActionResult Index()
{
    return this.View(this.BuildIndexViewModel());
}

So this.BuildIndexViewModel() is responsible for creating the viewmodel class (obviously :). But we're looking into the possability of:

public ActionResult Index()
{
    return this.View(ViewModelFactory.CreateIndexViewModel());
}

This is an interesting idea, but I'm not 100% convinced. I was interested in other people's opinions on this.

Best Answer

In this case I would say the best guidance to follow would be the GRASP principles. In particular look at the four criteria of assigning object creation:

In general, a class B should be responsible for creating instances of class A if one, or preferably more, of the following apply

Instances of B contains or compositely aggregates instances of A
Instances of B record instances of A
Instances of B closely use instances of A
Instances of B have the initializing information for instances of A and pass it on creation.

Your controller class (B) matches the items #3 & #4 of that list (and #2 if the viewmodel is POSTed back) , so it's already a very sensible place for the viewmodel (A) construction behaviour to live. As I see it there would only be two reasons which would compel me to extract that construction behaviour into a specialist class.

DRY - If two or more controllers need to share the viewmodel construction behaviour, encapsulating it in a distinct component would facilitate code re-use and avoid duplication.
If the construction behaviour has dependencies on other system components such as repositories, validators etc, and you don't want to introduce this coupling to the controller itself (in GRASP terms, a pure fabrication).

Looking back at those 4 object creation criteria in GRASP, I would only extract the behaviour to a separate factory if it won me an extra tick on that list. Otherwise there wouldn't be any value in doing so.

Hope that helps!

Related Solutions

Java Factory Pattern – Looking for Better Implementation

Your approach sounds good to me. Philosophically, while your factory does know about every subclass, it doesn't know that it knows. In other words, in the future subclasses might be generated elsewhere, in places your factory knows (and cares) nothing about. At the other end, the users of these subclasses neither know nor care where they came from. Might be from the factory, might be from somewhere else.

Your bad feeling on this is that you are replacing a simple mechanism with a fancy one, and you don't (yet) really need the power you are getting. You may indeed be wasting your time. But if your system grows, you might have several factories, and many other objects might create these subclasses, including the subclasses themselves. So long as your factory does not need to know about all the subclasses, and so long as your "consumers" don't need to know which factory, if any, they came from, your design is sound. Everything is properly encapsulated and polymorphic.

One other thing: in Java more so than in other languages, a subclass often works better than putting a switch in the base class. In Java I'll subclass anything if I need a slightly different behavior. In C#, I'll go to a lot of trouble to make one class highly flexible with extra fields and extra constructor parameters. A new Java class can be created in a small block of code with no references to it elsewhere--a local or anonymous class. In C# the new class has to be placed well away from the only spot to reference it as anything but its base class--and it may be several levels of base--or interface.

ASP.NET MVC – Role of ViewModels in MVC and 3-Tier Architecture

main MVC project, where M of MVC was moved to Data Access Layer

Common misconception. The M of MVC has nothing to do with data, despite the many examples and tutorials that claim so.

M is your ViewModel and should reside in your MVC project. The ViewModels you have in your BLL are actually to be named DataContracts or BusinessModels.

In your controller you have something comparable to this:

Get(id):
    dataContract = _service.Get(id);
    viewModel = Map(dataContract);
    return viewModel

In your service, something like this:

Get(id):
    dataModel = _dataAccess.Get(id);
    dataContract = Map(dataModel);
    return dataContract;

And in the DataAccess, you perform the proper joins according to the object requested. You are however of course free to add custom methods to your DataAccess when required, so your service can call those methods:

GetWithBars():
    dataModels = _repository.Query("select from foos join bars");
    return dataModels;

Best Answer

Related Solutions

Java Factory Pattern – Looking for Better Implementation

ASP.NET MVC – Role of ViewModels in MVC and 3-Tier Architecture

Related Topic