PseudoCQRS: The Query Side

The Controller

Finally, we just need to write a controller that will wire all the bits up and return the HTML to the browser:

public class DinnerListController : BaseReadController<DinnerListViewModel, DinnerListArguments>
{
    public override string ViewPath
    {
        get { return "Dinner/List"; }
    }
} 

You can see that we use one controller per action, and in this case the controller inherits from our BaseReadController object, which is a generic object requiring the type of the ViewModel and the ViewModel arguments as its generic parameters. Then all we need to do is tell it where the actual View for this screen is stored (the "ViewPath" override) and we're done!

So for each new screen in your application, the above are the only items that you need to create; a Controller, a View, a ViewModel, a ViewModelProvider and an arguments object to hold the arguments for the ViewModelProvider. Each of those objects has one responsibility, and if the screen needs to change, these are the only items that you would need to modify, and if you modify them you can be confident that you haven't affected any other features in your application. (Of course, you would want to have a suite of unit and acceptance tests in place to prove that...)

The PseudoCQRS components that use the above objects in order to display the data are as follows:

The BaseReadController

For the query side of PseudoCQRS, we provide two base controller which can automatically do all the necessary wire up. These are the BaseReadController and the BaseReadExecuteController. The BaseReadExecuteController will be discussed in a later article, but the BaseReadController is listed below:

[DbSessionManager]
public abstract class BaseReadController<TViewModel, TArgs> : Controller, IViewPath
    where TViewModel : class
    where TArgs : new()
{
    private readonly IViewModelFactory<TViewModel, TArgs> _viewModelFactory;

    public abstract string ViewPath { get; }

    protected BaseReadController( IViewModelFactory<TViewModel, TArgs> viewModelFactory )
    {
        _viewModelFactory = viewModelFactory;
    }

    public BaseReadController()
        : this( ServiceLocator.Current.GetInstance<IViewModelFactory<TViewModel, TArgs>>() ) {}

    public virtual ActionResult Execute()
    {
        return GetActionResult( _viewModelFactory.GetViewModel() );
    }

    protected virtual ViewResult GetViewResult( TViewModel viewModel )
    {
        return View( this.GetView(), viewModel );
    }

    protected virtual ActionResult GetActionResult( TViewModel viewModel )
    {
        return GetViewResult( viewModel );
    }
} 

This object is a generic base object which takes the type of a ViewModel object and the type of a ViewModelArguments object as its generic parameters. Into the controller is injected an IViewModelFactory object of the same generic types. Each controller has just one action - an "Execute" action. That action calls the ViewModelFactory to get the ViewModel and then returns the appropriate action for that view. By default, that's just to return an MVC ViewResult, using the ViewModel as its model, but the two methods GetViewResult and GetActionResult are marked as virtual so they can be overridden to return JSONResults or ContentResults etc.

The ViewModelFactory

The ViewModelFactory is responsible for getting the view model arguments object, passing that to the ViewModelProvider and returning the ViewModel to the controller. Its code listing is below:

public class ViewModelFactory<TViewModel, TArg> : IViewModelFactory<TViewModel, TArg>
    where TViewModel : class
    where TArg : new()
{
    private readonly IViewModelProvider<TViewModel, TArg> _viewModelProvider;
    private readonly IViewModelProviderArgumentsProvider _argumentsProvider;
    private readonly IPrerequisitesChecker _prerequisitesChecker;

    public ViewModelFactory(
        IViewModelProvider<TViewModel, TArg> viewModelProvider,
        IViewModelProviderArgumentsProvider argumentsProvider,
        IPrerequisitesChecker prerequisitesChecker )
    {
        _viewModelProvider = viewModelProvider;
        _argumentsProvider = argumentsProvider;
        _prerequisitesChecker = prerequisitesChecker;
    }

    public TViewModel GetViewModel()
    {
        var args = _argumentsProvider.GetArguments<TArg>();
        var checkResult = _prerequisitesChecker.Check( args );
        if ( checkResult.ContainsError )
            throw new ArgumentException( checkResult.Message );

        return _viewModelProvider.GetViewModel( args );
    }
}     

ASIDE: As with all objects within PseudoCQRS, ViewModelFactory implements an interface (in this case IViewModelFactory) that you could implement yourself if you wanted the factory to work in a different fashion. You then just need to wire up your IoC container accordingly to point to your implementation and not the PseudoCQRS implementation. All the PseudoCQRS components can be replaced in this fashion if necessary.

The ViewModelFactory gets a ViewModelProvider (in our example, that's the DinnerListViewModelProvider), an IViewModelProviderArgumentsProvider and an IPrerequisitesChecker objects injected into it. It uses these objects as follows:

1) It calls the IViewModelProviderArgumentsProvider object to get the arguments required to pass to the ViewModelProvider

2) It sends that arguments object to the IPrerequisitesChecker. That object can do things like make sure this user has access to the object specified by the arguments, or check to make sure the arguments are well formed etc.

3) If the IPrerequisitesChecker is happy that everything's ok, it then calls the GetViewModel method of the IViewModelProvider with the arguments, and returns the result.

The ViewModelProviderArgumentsProvider

The ViewModelProviderArgumentsProvider is responsible for constructing the arguments object that is sent to the ViewModelProvider:

public class ViewModelProviderArgumentsProvider : IViewModelProviderArgumentsProvider
{
    private readonly IPropertyValueProviderFactory _propertyValueProviderFactory;

    public ViewModelProviderArgumentsProvider( IPropertyValueProviderFactory propertyValueProviderFactory )
    {
        _propertyValueProviderFactory = propertyValueProviderFactory;
    }

    private readonly PropertyInfoCacher _propertyInfoCacher = new PropertyInfoCacher();

    public TArg GetArguments<TArg>() where TArg : new()
    {
        var retVal = new TArg();
        var properties = _propertyInfoCacher.GetProperties( typeof ( TArg ) );
        var propertyValueProviders = _propertyValueProviderFactory.GetPropertyValueProviders();
        foreach ( var propertyValueProvider in propertyValueProviders )
        {
            foreach ( var kvp in properties )
            {
                if ( propertyValueProvider.HasValue<TArg>( kvp.Key ) )
                    kvp.Value.SetValue( retVal, propertyValueProvider.GetValue<TArg>( kvp.Key, kvp.Value.PropertyType ), null );
            }
        }
        return retVal;
    }

    public void Persist<TArg>() where TArg : new()
    {
        Persist( GetArguments<TArg>() );
    }

    internal void Persist<TArg>( TArg arguments )
    {
        foreach ( var property in typeof ( TArg ).GetProperties().Where( x => Attribute.IsDefined( x, typeof ( PersistAttribute ) ) ) )
        {
            var persistLocation = ( Attribute.GetCustomAttribute( property, typeof ( PersistAttribute ) ) as PersistAttribute ).PersistanceLocation;
            var propertyValueProvider = _propertyValueProviderFactory.GetPersistablePropertyValueProvider( persistLocation );
            var propertyValue = property.GetValue( arguments, null );
            if ( propertyValue != null )
                propertyValueProvider.SetValue<TArg>( property.Name, propertyValue );
        }
    }
} 

This object works in pretty much the same way that the standard MVC ModelBinders work - it looks in the Querystring, the Form, the RouteData, the Session and the Cookie objects for entries matching the names of the properties on the object that it is constructing, and if it finds any such items, it sets the property on the object accordingly.

The GetArguments method works as follows:

1) It creates a new object of type TArgs. In our example, that means it creates a new DinnerListArguments object.

2) It calls a PropertyInfoCacher object to get a list of all the property set methods on that object. The PropertyInfoCacher uses reflection to get this list of set property methods, and once it has looked them up for a particular type, it caches them so they can be retrieved more quickly the next time.

3) It calls the IPropertyValueProviderFactory to get a list of PropertyValueProvider objects to use in order to try to set the properties on the arguments object. The implementation of IPropertyValueProviderFactory in PseudoCQRS returns PropertyValueProviders that look in the following places for property values (and in the following order):

• Cookie
• Session
• RouteData
• QueryString
• Form

4) It loops through each of these PropertyValueProviders asking them if the can provide a value for each of the properties on the object, and if they can, it sets the value on that property accordingly.

5) Finally, it returns the arguments object.

For our example, the DinnerListArguments contains just one property, the HostedByUserId property. So the ViewModelProviderArgumentsProvider first checks to see if there is an entry in the Cookie object named "HostedByUserId", and if there is one, it tries to set the value of the property to the Cookie's value (if it can be converted to an integer. If it can't it just ignores it). The it checks in Session for an entry named "HostedByUserId". Then RouteData. Then the QueryString, and finally, the Form. In all cases, if it finds an entry, it sets the value accordingly, so a Form entry will override a QueryString entry, which will override a RouteData entry etc etc etc.

In our example, when you change the "Filter by Host" drop down list, it causes a get request with a HostedByUserId entry in the querystring. So when the ViewModelProviderArgumentsProvider returns the DinnerListArguments object, the value of "HostedByUserId" will be the value that it finds in the querystring.

One other thing to note about the ViewModelProviderArgumentsProvider object is that it has a Persist method on it too. This method can be used to persist any values in your arguments object that you want to store in a persistable format - ie, to Session or to Cookies (or to whatever other persistance mechanism you want if you write your own PropertyValueProvider objects). This method will look for any properties on your arguments object that are decorated with the "Persist" attribute, and for those properties, call the SetValue method on the appropriate PropertyValueProvider which should implement the persistance mechanism. This feature is useful in cases where you want to persist the state of the screen somehow so when you come back to the screen, the same data is displayed (for example, the same page of data on a paged list).

That's basically it! Once the arguments object has been created, it is sent to the ViewModelProvider that we wrote, and that object returns a ViewModel to the ViewModelFactory, which in turn returns it to the Controller, which in turn selects the View to use to display the data and it is returned to the caller accordingly.

PseudoCQRS takes care of all the boilerplate code that you might otherwise have to write when creating query screens for your application. The only things you need to write are the things that are specific to that actual screen (the View, the ViewModel, the ViewModelProvider etc).

In a later article I will describe the command side of the architecture where the user can actually make modifications to the state of their data.

The code for the framework can be found at the PseudoCQRS repository on GitHub

You can also install PseudoCQRS via NuGet (MVC4 and MVC5 versions are also available).

SOME NOTES:

I have not gone in to complete detail on all the objects that are involved in the query process. For example, you will note that the BaseReadController is decorated with a "DbSessionManager" attribute which actually deals with opening and closing the connection to our database so the ORM queries work. Similarly, I haven't fully explained how the PrerequisitesChecker works, or how all the objects get injected into the objects that rely on them. These topics are beyond the scope of this article, but in the example application on the GitHub repository, you can follow the code through in a debugger to see exactly what everything is doing, or read up on NHibernate sessions, Inversion of Control containers, AOP concepts with regards to attributes etc to find out more.

We have also created a PseudoCQRS Bootstrap project which will do all the bootstraping necessary to get a project working with PseudoCQRS and the following technologies: Unity, AutoMapper, FluentValidation and NHibernate. Again, these items are outside the scope of this article, but if you have any questions, please feel free to ask in the comments section.