Over the past few months, I have been deep down the rabbit hole with .NET MVC web application projects. A pattern of development emerged out of these months of work, which I want to share with you today. I am not sure what to call it, but MVC Squared seems to fit. In reality, it is more of a .NET model-view-controller server side design with a view-controller, view-model client side design. One night I sat down to create a pseudo flow chart of my idea, so others working with me could critique it.
The new implementation for me was the client side architecture. After coming across knockout.js for an internal project, I started to really love what it was doing and how I could use it to develop client side code in an entirely new paradigm. With a MVVC (model-view view-controller) binding tool, like knockout, we can develop solid code “classes” in javascript and not put a lick of DOM manipulation or references in our classes.
That is entirely possible by the ability of knockout to bind HTML elements to javascript objects, instead of our javascript objects “binding” to DOM elements. For our team, this meant the programmers can bang away at making amazing functionality and interactions, while the front end design group can bang away at making CSS and HTML without any of the javascript breaking when the project comes together. This improved our team’s workflow. In order to easily bind these html elements to a javascript object, the view model emerged (credit goes to knockout.js and their definitions of how to use their library).
Once we started to have javascript view model classes and basic properties in them, the need was to get the appropriate data to the view models. The traditional way of getting data to a client side javascript script was to have it all in the initial response from the server. What this tends to do is bloat the initial response from the server, possibly causing larger load times than actually needed. I want to throw an emphasis on “possibly”; since sometimes the data may be needed for the initial page. In a lot of my last projects this wasn’t necessarily the case though.
Lets take, for example, a products page. We may have hundreds or thousands of products in a database which we want to give to the user in an elegant and non-postback implementation. This is where the new pattern shows its strengths!
On the client side we have one view model class for a single product, and then create new instances of that class for each product, while pushing them into a javascript array. We only create the new view model for the products that need to be shown at this given instance and as the user wants more, we dynamically create and load on demand. The initial page load is not bloated with all the product’s data and our user interactions can be implemented seamlessly without postbacks and with elegant javascript animations.
How do we get the product data into the view model? This is where a neat little view controller javascript object pops up. The view controller is just like a server side controller by the way it holds, loads, saves, and maps the data from the server to the view. With a little help from AJAX, we can asynchronously get the data from the server, map it to a new view model, store it to an array in our view controller, and then allow knockout’s bindings to update the DOM accordingly.
This design also allows us to separate our javascript logic by views. Personally, I create a new javascript file per view, where each file holds its appropriate view model and view controller definitions. This makes it easy to stay organized, and easy to find the area you need to work in or update.
Now that we need to talk to our server with AJAX, our server code needs to implement the actions for the AJAX get and post requests. Since I am mainly a .NET developer, this is where some of you may exit. If so, then you probably already know how to implement those functions in your respective language. Just remember that to make your life easier make sure your server models match your client side view models. This will make data more consistent and easier to work with when going from server to client side.
For .NET Developers – My Implementation
For those that are .NET developers, here is a simple description of my implementation. In .NET MVC we already have our simple MVC setup. I started to create my post and get actions in my normal controller but then started to get confused with the large code files I was creating. My controllers were holding all the normal functional actions plus my AJAX actions. I decided to implement a new controller, with the same name but appending an “AJAX” after my controller name. Then some simple inheritance from my standard controller gave me a separation of logic and files to work with.
I really loved this idea so I stuck with it for all of my work thus far. Since the AJAX controller is not creating views, we don’t have to worry about our view structure getting confusing or larger. Also, since our AJAX controller is being inherited by our standard controller, all normal URL routes of controller/action will work properly; even from the javascript through our AJAX calls. All that is left is creating our new actions, getting the appropriate data from our repository (or database if you are not using an entity mapping structure), mapping that data to a pure model and returning it in a JSON result. Quick, easy, and amazingly simple to test and implement.
I feel this is just touching on the amazing things that can happen with a predefined structure of this nature. Now I find myself working on traditional sites and saying to myself, “If I had view model binding here and AJAX, this could be done a lot better and with nicer user interactions”. You may have noticed that I did not start to touch on unit testing, but if you are the unit testing type, then you can already see how this structure lends to make unit testing easier and not dependent on the DOM. I also attempted to keep this article a little more about theory and architecture instead of examples. For those that are more of the hands on learners, I will post back soon with some code examples.
Hopefully I have either taught you something to help your day, or intrigued you to criticize my idea. Either way, I would love to hear your opinions and comments!
