Theory behind MVC (Model – View – Controller)

My greediness to exploring technology drove me to look into ASP.NET MVC technology few months back and started to do great deal of R&D work during that time. So I thought of blogging the things I have learnt so far and the best way to start is to look into the theory behind this.

So what is this MVC stands for Model View Controller. According to the definitions that I followed, there are three components in this as its name defines: a Model, a view and a controller. This is an alternate for ASP.NET web forms. Some high level features of this technology include ease of use, highly testable and light weight. One interesting thing about this is that majority of developers are familiar with this technology and some types of web applications, not all, will benefit from this. On the other hand there could be applications that could use both technologies, but what ever the technology that we use should have a balance between Cost, Quality and the Budget. I’m sure that all will agree that our ultimate goal is to stick to these three pillars.

Let’s have a closer look at the separation of the model. In each explanation that I referred on the web was having the same fundamental illustration as bellow, but I’ll try my best to illustrate it more further on a separate diagram.

Following is a high level illustration of the flow of control and data within the pattern.

So how does this separation maps to your application. The View concentrates on the UI logic. The Model defines the business logic and the controller handles all the input requests. Since these components are separated it enforces loose coupling and determines the location of the each component in the application. This removes the complexity from the development of complex business solutions. Apart from the complexity it enables the automated test scripts to be written in isolation. For example if one would want to automate the Model in separation. This separation also allows parallel development which is an excellent feature to keep the time component under control. For example different developers and UI engineers could work on different layers. i.e. developers could work on both the Controller and the Model. UI engineers can also work on the View component of the application.

The underlying behavior of the Model is, it doesn’t always have to be a relational data source or use of the entity frame work. It could be a service, a queue, etc. So it could be any data source and it doesn’t dictate what your business logic will looks like. In fact it doesn’t care about the underlying layers of your application which means that MVC is building a UI and nothing more.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s