I’ve been writing a whole bunch about MVC architectures – client side and server side. But I hit a problem. You see, MVC and MVVM are pretty simple concepts. Here is a typical diagram that I see when looking at MVC descriptions:
It’s nice and simple. The controller loads the model and passes some form of data to the View. The problem is this – where is the user and where is the data? How do these actually interact? This is actually a key point in understanding the architecture and the place that frameworks – any framework – occupies in the architecture. I think the following is a much more representative architectural diagram:
This makes more sense to me. The user submits a request to a dispatcher. The dispatcher decides which controller to pass the request to. The controller asks the adapter to give it one or more models to complete the request. In the case of MVVM, these models are transitioned into a View-Model, usually through some sort of data binding. This new model (or view-model) is passed into the View rendering system, which renders the appropriate view and kicks it back to the core dispatcher so that the dispatcher can respond to the user.
It’s much more messy than the plain MVC (or MVVM) design pattern. However, it’s implementable and I can see the pieces I need to implement in order to achieve the desired web application. This architecture can be implemented on the client side or the server side and both sides have frameworks that assist.
Frameworks provide some sort of functionality that allow you to ignore the boiler-plate code that inevitably comes with writing such an architecture. Most frameworks have some sort of dispatcher (normally called a router, but they do much more than that) and most frameworks have some sort of adapter logic (mostly called an ORM or Object Relational Mapper). In between, frameworks enforce a pattern for controllers, models and views that can be used to enforce consistency across the application.
- ASP.NET provides the dispatcher, with an ability to configure a route map in it’s startup class.
- The Controller class can be inherited to create custom controllers
- The Model is a plain-old class
- The View is handled by Razor syntax
- The Adapter is generally handled by Entity Framework.
- Node and ExpressJS provides the dispatcher, with a crude route mapping step
- I’ve recently blogged about my Controller class that can be extended to create custom controllers
- The View is handled by EJS or EmbeddedJS
I haven’t really gotten into Models and Adapters, although I can see libraries such as Mongoose (for MongoDB) playing a part there. However, there are Node/Express MVC frameworks out there – I want to investigate Locomotive and SailsJS at some point, for example.
On the client side, things are definitely more messy. There are a host of different frameworks – Angular, Aurelia, Ember, Knockout, Meteor, React / Flux, along with a host of others. I’ve found the TodoMVC site to have a good list of frameworks worth looking at. Some of these are being upgraded to handle ES2015 syntax, some are already there and some are never going to be there.
One thing to note about frameworks. They are all opinionated. ASP.NET likes the controllers to be in a Controllers namespace. Angular likes you to use directives. Aurelia likes SystemJS and jspm. Whatever it is, you need to know those opinions and how they will affect things.
The web isn’t the only place one can use frameworks. The MVC architecture is not limited to web development – it’s constant across applications of any complexity. For example, you can see MVC in WinForms, Mobile applications, Mac OSX Applications and Linux Applications.
I want my application to be rendered client-side, which means I need to take a look at client-side frameworks. My working list is:
I’m not going to bother with Backbone, Meteor, Knockout or any other older or smaller framework. This is my own time and I don’t want to spend a ton of time on investigation. I pretty much know what Aurelia can provide. To investigate the others I needed a small site I could implement – something that wasn’t “just another task organizer” (TodoMVC). To that end, I decided to create a three page application.
- Page 1 – the home page – will get loaded initially and contain a Polymer-based carousel
- Page 2 – a linked page – will load data from the Internet (the Flickr example from the Aurelia app)
- Page 3 – an authenticated page – will load data from the local server if the user is authenticated
In addition to the three pages, I’m going to ensure that the navigation is separated logically from the actual pages and that – where possible – the pages are written in ES2015. I want separation of concerns, so I expect the models to be completely separate from the views and controllers.
Each one will be implemented on top of a Node/ExpressJS server that serves up just the stuff needed. In this way, I will be able to see the install specifics. You can see my starter project on my GitHub Repository. I hope you will enjoy this series of blog posts as I cover each framework.