Creating software people love!

MVC is Not Dead

Monday, March 6, 2017
Derek Maciak / Software Superhero

Is MVC Dead? I don't think so!

Within the last 2 years I was in charge of developing a responsive web-based Line of business UI that would compliment an existing WPF UI that used the MVVM pattern. The mission was to reproduce the desktop experience on the web while reusing all the business and validation logic that was developed for the WPF UI. The new web based application needed to be responsive so that all functionality could be accessible by any device while maintaining a great user experience. Let me take you through the thought process and the design decisions we made as a team to accomplish this mission. Is MVC dead? I don’t think so. Let me explain.

Accelerator High Level Software Architecture DiagramAccelerator High Level Software Architecture Diagram.

First of all, I was lucky that the WPF application was architected and designed to consume services and that all validation and business logic was centralized in non-visual C# classes. Take a look at our architecture diagram . I have always grouped business logic into 3 categories: Validation logic, Business Processing logic and View/State logic. Since we develop using .NET, let me go into some details regarding how we support these 3 areas. For validation logic, we use attributes on the properties defined in our entities. During the development of our WPF UI, we created a bunch of validation attributes that can simply be added to properties in the entity. By creating wrappers around the WPF controls, we were able to build in some really cool intelligence that gave the user feedback based on the specific validation attributes. We even started using attributes to centralize how information was displayed to a user, which led us to group our attributes into 2 categories: Display and Validation. The power of these attributes is that they are centralized and data can be validated on the client as well as on the server. You just can’t assume the services will be called by a UI that has properly validated the data. Once the data has been validated, the business processing logic takes over which runs on the server. Obviously any issues during that process can result in an error that the UI can react to. The view model in our WPF world runs on the client. We designed our view model to be able to set the state of UI controls including commands. Something as simple as setting commands to be disabled or hidden based on data was coded in the view model. Again, my mission was to reproduce this WPF desktop experience on the web while reusing as much of the business logic as possible in order to take advantage of that huge investment. So now that you have a background on our implementation of business logic, how did we accomplish creating a desktop-style line of business web application that reused this investment?

A Single Page Application: Client Side MVC, Server Side MVC or Both?

Since I was creating a Line of business application, I knew I needed to create a Single Page Application as I wanted to allow an end user to determine what and how long information needed to stay in the browser view while allowing them to explorer additional information and other areas of the system just as they would with the WPF rich desktop experience. In this post I can’t go into details regarding all the UX design decisions, but we spent a lot of time on the user experience. Because I was creating a SPA, I decided to look into the popular client side frameworks such as Angular (Version 1) and React. I worked with Angular v1 for a couple days and found a limitation with the framework at that time. My design needed to support loosely coupled modules/components that could be loaded independently as separate views within the same page. Angular v1 did not make it easy to support multiple views on the page but I believe support for this design has now been added to angular 2. At that time, I moved my attention to React which is more focused on the view. For my client side needs, I ended up not using Angular and created my own framework that catered more specifically to my needs. I use React when needed. I also made the decision that it was best to have a balance between the responsibility of the client and server and to support a high level of code reuse. I was against coding business logic in JavaScript and then coding it again on the server in C#. I needed to find a solution for this. Since the application I was bringing to the web was using .NET, I knew I wanted to use ASP.NET MVC for my server side MVC framework. This hybrid approach allowed me to have a client and server side MVC framework. Once the main page layout was rendered by MVC, I was able to deliver module/component views to the client via AJAX calls to the controller. This allowed me to create a Single Page App and leverage the server-side scripting capabilities of ASP.NET MVC for my individual component views. The design worked out perfectly and allowed me to utilize the power of a server side MVC framework and the custom jQuery plugins I created that provided the data binding and routing I needed for the client side MVC framework.

So how did I pull it all together?

If we just consider validation logic for a moment, I knew I wanted to reuse all the validation logic that was written in C#; but of course that can’t run in the browser. And I didn’t want to have just server side validation logic. I wanted to make sure that as much validation logic as possible (or that made sense) was delivered to the client. In looking at how I handled this in WPF, I created intelligent WPF UI control wrappers that worked with attributes in the entity. So I decided to try this same technique out in the web world. My first step was to refactor the C# attributes to inherit and extend the MVC data annotations attributes. This allowed me to tap into some of the development that Microsoft already did. You can read more about data annotation attributes here . I was also able to wrapper the html controls I was using with some intelligence to react to the attributes on the properties within my entity in the same way that WPF did. The end result was that I now had validation and display attributes that played nicely with the WPF and Web world. These web UI controls use a combination of JavaScript, custom jQuery plugins and html data attributes. The html data attributes are applied on the server side after evaluating the various attributes in the entity and delivered to the client as view components via an AJAX call. I accomplished the ability to centralize my validation logic that can now be used by WPF and ASP.NET MVC that also gives me the ability to have client side and server side validation. When developing web applications, I was never a fan of coding validation logic in JavaScript and then having to recode the same logic in C# for the server side. This solved my problem.

The next hurdle was to reuse the C# View model display state business logic. This is code that sets the state of the UI controls including the commands. For the time being, I was able to tap into this logic by creating a couple generic services that pass in the current client state via an AJAX service call and allows the view model to change the state. One of the concerns I had at the time was whether this approach would be too chatty as the client is being triggered to call the server to determine if state should change. So far it hasn’t been a problem and has surprisingly worked out very well. I can always revert back to coding some of the state in JavaScript, but if I can reuse code without an impact to performance or to the User Experience in general, I will opt for the centralization of code.

Is MVC dead? I don’t think so.

In my case a client-side MVC framework just wasn’t good enough and I needed the power of a server-side MVC framework. Tapping into the power of both provided me a lot of additional benefits. At the end of the day, I think there can be a happy medium between client and server coding. There are pros and cons to having a very thick JavaScript client as well as to having everything on the server. I was able to take the good from both sides and create a very powerful line of business application that will be easy to maintain and scale. You can try the ASP.NET MVC line of business out for yourself. I have posted several demos . Please feel free to reach out to me if you have further questions or want to talk about our design approach in more detail.