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.
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?
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
Is MVC dead? I don’t think so.