MVC architectural pattern.

-

Step by step understanding of MVC model –

There are many ways we can define and understand MVC model. I am explaining it from a design perspective, trying to give an idea that how we started at very early stage in software designs and about evolution of MVC architecture design in software systems. I will explain how we were designing software systems in very early stage and step by step adaptation towards to MVC model.

In early stage we used to make software systems (or solutions) like a white box system. Think about a white box system. A system whose internal component/module are open (or shown to outer world) is called a white box system. Read about white box system to understand MVC better.

 I am explaining white box system below –



This is a system (or solution or application) called X, which has 4 different modules in it(there could be more number of module present in any system).

Let me evaluate this old design through 5 basic design parameter of a good design and show you why it is not a good design. 

 If you have not read 5 basic design parameter of a good design, I would recommend you to read it first to understand evolution of MVC design in software systems better.

1.       Usability –

-          As of now, 4 modules are present and shown to user (like a white box), user has to know about each module (how to call it, what parameter to pass). This is just a small example think about a real solution where we have 100+ module, remembering them all and calling them according to your need is pain.
-          It is required to memorize so many things.    

2.       Performance –

-          Each time call comes back to user and he will execute other module according to his need. All this time user will make a remote call which is very costly.
-          Suppose one full transaction will get completed through 2 different modules (like to transfer money to others account you have to first withdraw from your account then transfer/deposit to target account, 2 different operation through 2 different module). As per current design you have to make 2 remote calls which is costly and performance will go down.

3.       Flexibility –

Flexibility means if you introduce any structural and behavioral changes your client will not get affected.
a.       Structural flexibility –
-          In current design, if you introduce any new structure your client has to update new behavior of that structure, as it is one to one mapping between client/user and module.
b.      Behavioral flexibility –
-          If you change the way modules are talking to client/user or to each other or the core logic of execution, user will get affected and you will have to change the full system again.

4.       Security –

There is no room to talk about security as all component are shown to outer world.

5.       Accountability –

There is no module which is accountable to execute any functionality. It is on client/users shoulder.

Introducing controlled entity –

Controlled entity is one level of indirection(an interface) to module. We can club related functionalities in one controlled entity.

For example. I want to transfer money to Mr. X. Two operations are involved here
a.       withdraw from my account.
b.      Add/deposit same amount to Mr. X.

If you see functionally, I am transferring money, deposit and withdrawal are 2 different operations in it. So we can have a controlled entity of transferring the money.

Now design looks like this -


Let me evaluate this design with 5 basic design parameter of a good design –

1.       Usability –

-          Now user is happy, as he don’t have to remember all the functionality. He will just tell controlled entity to perform one operation (transfer money in our case) to its controlled entity. It's controlled entity headache to complete the operation.

2.       Performance –

-          Indirection will include slowness as usual.
-          But as we are able to reduce 2 remote calls (or n number of remote calls), it will be fast. Now only one call will get passed and all other internal calls will be local calls.

3.       Flexibility –

a.       Structural flexibility –
-          Now if I add any new module to make system fast, client/user will not get affected, as they are talking to controlled entity and not to the module directly.
b.      Behavioral flexibility –
-          Client/user will not get affected even if I change some behavior (or core logic) of internal modules or change the way modules are talking to each other to achieve better performance.

4.       Security –

a.       Structural security –
We have achieved structural security by hiding internal modules from outer world.
b.      Behavioral security –
We failed to achieve it. As per current design, all kind of users(like admin user/basic user etc..) will have access to all existing controlled entity.

5.       Accountability –

We have achieved accountability as you can see now that controlled entity (transfer money) is responsible for transaction.  In current design if anything goes wrong, we can rollback transaction until its get completed in all sub modules

Introducing boundary entity –

Why?

-          There are so many roles or say types of user who will use your software like –
a.       Administrative role.
b.      Manager/supervisor role.
c.       Worker /user role.

It is not a good idea to show all functionality to all types of users. First, it is not good idea in security perspective. Second, why you want to show the functionality which is not relevant to the role. In this case, user has to remember out of n numbers of functionality what n’ (n dash) numbers of functionality is useful for him. 


Now let me evaluate this design with 5 basic design parameter of a good design –

1.       Usability –

-          Once I am logged in to the system, I will see functionality related to my roles and responsibility. I don’t have to remember what all controlled entity exists inside the application.
-          Ultimately we have reduced the burden of user and made system which is easy to use.

2.       Performance –

Compared to our first and second design, we have reduced the performance by introducing one more level of indirection to achieve better security and usability.

3.       Flexibility –

Introducing indirection in design will make it flexible. This is highly flexible now.

4.       Security –

We have achieved structural as well as behavioral security in this design.

5.       Accountability –

Much better now.

Now you can see and understand that, after we have introduced boundary entity we have achieved all our design goals, at this stage our design follows MVC (model view controller) architecture.  

MVC structure –

There will be thousand of diagram available in internet on MVC model, I have taken one from Microsoft's .net framework.

 M => model (N number of modules or functions)
V => view (Boundary entity in my explanation)
C => controller (controlled entity in my explanation)


Thanks for reading it. To read more on design patterns and basic design principles please see my web page. You can also join me on FB or on G++. Please drop comments for any question related to this blog.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post cleanups/conditions,
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one layer. Layer
Read more

Architectural style -> Adoptable system -> Reflection.

-
Image
Background - We have discussed very less about reflection, especially if you are C, C++, mainframe, LSI developer and working on server side implementation or in low level hardware-interaction development team.  But it is very popular among high level languages like JAVA, Scala, C#, Python etc, many languages have implemented reflection in it.  It gives you flexibility to do things dynamically (at run-time). After working closely with different clients, you will get a clear understanding that no one is as confusing as a software client, not even your girlfriend! So we should have a flexible architecture in place who can absorb shocks of client’s last moment changes. Not only that, sometimes we have N number of different behaviors and structure in place, and we want our application to behave differently depending upon run-time situations. Let’s build understanding step by step through an example. Think you have got an assignment where you have to build an application
Read more