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.
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)
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.
Very Informative.
ReplyDelete