ASP.Net MVC High Level Architecture

This article is intended to narrate MY OWN way of implementing ASP.Net MVC in many of recent projects which I have architected. On the first hand, I would like to describe the phrase – “MY OWN”, then we will move forward with a brief description of below high level architecture.

Over the period of time say from early 2000s, especially after the evolution of ASP.Net MVC (I am specifically talking about Microsoft Technologies), developers found out different ways to get GRANULAR control on code which is more flexible to agile development processes. In the process of this granular investigations, most of the developers gave importance to some specific strategies like Domain Driven Development, Test Driven Development, Loosely coupled systems, Code Maintenance, Separation of duties etc. Most of the afore said strategies can be achieved through the way of COMPONENTIZATION techniques. There are different ways to separate your code into components, and here comes MY WAY of generating components.

ASP.Net-MVC-Architecture

 

As a first step in planning a MVC framework application or product, I would start with a strong Model (typical C# props). I usually spend time with business people understand their business processes and workflows, I would concentrate (give first preference) more on how I can solve their problem in a natural way, rather than changing their existing workflows. This process is going to take most of your time, believe me and it is at times way too boring, but by the end of these sessions I would land up with my strong MODEL classes (at least to get start). Model classes are real world representations of data in business domain. Don’t take me wrong in differentiating Database and Model classes, there can be existing Database which we might need to work on with or might need to come with a new data design. In my perspective Data representation is whole together a new ball game (I am going to share my perspective about data designs in my future articles) with respect to identifying your application Model classes. For this article context I am going to be strictly confined with application Models.

Once my models are ready, I can get a fair amount of idea on my Repository classes, before which I am going to come up with my Repository Contracts (IDataRepository in above figure) which are typically Interfaces. I define contracts so that all parties which tend to interact with each other is going to have an exact idea about others through this contract. Repository component is just going to act like PUSH and PULL data from your persistent medium (say database). My repository component never going to have any idea on business logic.

As I have backend established, now I can concentrate on my actual business process implementation (technically). I will start putting up one more level of Contract (IBusinessLogic interface in above figure) which defines all business operations which are to be done using Model classes. This interface has been implemented by BusinessLogic Component which does the core business activity (specific methods for every business operation). This particular component will use Repository component to delegate business data to persistence medium.

With above step completed, I can easily go and build my Controllers which are going to be the first point of entry to my business logic and gets value proposition between Front End User Interface and Business Data. I can call my business logic component methods in my controllers and get my work done. From these controllers I am going to return ActionResults of my interest to Views and thereby present data to end user. Everything good till now, but there are many (most) scenarios where you don’t want to present complete Model data or might need to club two or three models to present data. In these particular scenarios I would recommend you to seriously consider having ViewModels in place. ViewModels are again typical C# Classes with basic properties (getters and setters). We can use this ViewModels in controllers, where you can get Model data and turn it to your ViewModel, then bind the ViewModel to View (Model Binding in ASP.Net MVC going to help in connecting ViewModel to View).

Above briefs explain you the architecture diagram which I came up with. The only point which I skipped in this above explanation is about Dependency Injection, which is used to make all subsystems more loosely coupled. I am going to come up with another article where I am going to explain how Dependency Injection works.  Narrated architecture encourages Agile development strategies, where developers need to agree on the contracts for their interaction with other components. This architecture also solves a specific business problem in a better way based on the fact that we have given domain models much better priority and drive the complete development on top of domain models.

Next part of this article is going to be a implementation of proposed architecture. Stay tuned.

You may also like...