Is MVC Dead? I don't think so!
Recently I came across a discussion that asked the question "Is MVC Dead?". It took me a bit by surprise. Over the last two years I was in charge of developing a responsive web-based line-of-business UI that would complement our existing Windows UI built with WPF (Windows Presentation Foundation) which uses the MVVM (model–view–viewmodel) pattern. The mission was to reproduce the powerful desktop experience in a web browser while reusing all the business and validation logic that was developed for the Windows UI. The new web-based application needed to be responsive, maintaining a great user experience with all functionality on any sized device. I did this with great success using ASP.Net MVC (model-view-controller). In all my experience and with all the people I worked with; – "Is MVC Dead?" No, I don't think so. Let me explain by taking you through the thought process and the design decisions we made as a team to accomplish this mission.
Architecture, Architecture, Architecture
First of all, I was fortunate that we had previously architected and designed the WPF application to consume services and have all validation and business logic centralized in non-visual C# classes. Take a look at our architecture diagram. For us great architecture is pivotal to future proofing your software and this project further proved that.
I have always grouped business logic into three categories: (1) Validation logic, (2) Business Processing logic and (3) View/State logic. Since we develop using .NET, let me go into some details regarding how we support these three categories.
- For validation logic, we use attributes on the properties defined in our entities. During the development of our WPF UI, we created validation attributes that can be easily 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 either Display or Validation attributes. The power of these attributes is that they are centralized and data can be validated on the client as well as on the server. As a developer, I would not want to 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 and was designed to be able to set the state of UI controls including commands. for example, something as basic as setting commands to be enabled, disabled, or hidden based on data and context was coded in the view model.
Again, my mission was to reproduce the WPF desktop experience on the web while reusing as much of the business logic as possible in order to maintain great architecture and take advantage of that previous 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 (LoB) application, I knew I needed to create a Single Page Application (SPA) 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 multi-task into other areas of the system just as they would with the rich WPF desktop experience. In this post, I can’t go into details regarding all the UX design decisions, but we have spent significant time on the user experience. It is, after-all, the first Pillar to Accelerating Software Development.
Because I was creating a SPA, I evaluated the popular client-side frameworks such as Angular and React. I worked with Angular (Version 1 at the time) for a couple days and found a critical limitation with the framework. 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 same page. (I believe support for this design has been added to Angular Version 2.) Because of this limitation, I moved my attention to React which is more focused on the view. For my client-side needs, I ended up creating my own framework that catered more specifically to our needs, using React where and when needed.
Pulling 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 the WPF framework 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 with data annotation attributes.
Is MVC dead? I don’t think so.