The idea behind MVC a.k.a MVO

Note: This article will cover the idea behind the (MVO) necessity, view, octopus, the concept of an architectural design pattern from a different angle if you are looking for MVC/MVP/MVVM definition, or some classical approaches of that concept please check the below links.

The idea behind MVC a.k.a MVO

In every software development corner, we always hear about these architectural design patterns, MVC, MVVM, and MVP, using them every day in several projects and frameworks, such as ASP.NET, Laravel, Symfony, Angular, and Vue, without any kind of a curiosity, why we do use these patterns ? do we need them anyway?, well, you might say that they help us to structure our code by making it more understandable, and it doesn’t matter which one is a perfect choice, but it depends on the project requirements.

The first phone architecture mystery

Let’s get back to the history, when humanity just discovered a new way to communicate, that was the first telephone, when you can make tube communication between emitter and receiver that requires tow telephones and one regular wire, that was just simple as it is, it works, but it becomes more difficult to connect more and more of telephones (nodes) that require more wires (edges) as well.

This is how it looks like.

Graphical Representation

In this case, for 8 nodes we need 36 edges to connect all the nodes to each other, the maximum number of edges possible in a single graph with ’n’ vertices is.

So you may ask that what is the optimal solution to optimize all these connections to a minimal value so it becomes easier for us to add more edges (telephones)?

Well, this is how we gonna do that, we simply add a central hub to our graph so we can connect all the nodes to it, in other words, there is no need to connect all the nodes to each other, all we have to care about is the central hub that would take the responsibility to connect all the nodes to each other.

Graphical Representation (octopus)

As you can see, we only need to connect each node with one single edge, so to connect 8 nodes plus the central hub we need 8 edges.

What do you think Thu? this is an efficient solution that we could implement to optimize telephone communication, I tell you what, do you know that we could project that concept on software engineering in real-life? especially on architectural design patterns, we are talking about the separation of concerns, believe me, you gonna love it!

Projection on MVC/MVP/MVVM

Ugh, It was such a pain to remember all these Terminologies MVC/MVP/MVVM since I was at the first year in the university, that was difficult to remember all of ’em but we could simply say that actually these terminologies just mean the same thing and are all solving the same problem, it’s the separation of concerns.

What is the separation of concerns specifically means for writing applications? we can separate our code into a few fundamentally different pieces, we’ll refer to them as M, V and O i.e Model, View, and Octopus.

Let me tell you a little bit about the Octopus, he really dislikes disorganized code so it’s separate our concerns, so what does that actually mean?, well, no matter what the size of the application, developers like to organize everything in a few buckets, let’s talk about them one by one.

The view

This is all the stuff that user sees and interacts with, that include DOM elements, buttons, input elements, and images, basically, this is the user’s interface to your application, both for giving your application data and for reading data.

The model

Where all the data is stored, that includes data from the server and from the user.

So the model and the view are connected specifically by our Octopus, so the Octopus is providing the separation of concerns that we desperately need when building an application, then you can think of the octopus as that thing that holds things together but also keeps them separate enough, to allow changes to the individuals pieces without ruining the rest, so I can change the view however I like without disturbing the model, or I can change the way I’m storing my data without disturbing my view.

Now what?

Well, MVC, MVP, MVVM are basically the same thing, they all fixing the same issue, separating our model from our view, in other words, we can think of Controller, Presenter or ViewModel as the octopus, using these patterns means actually that you’re using (n-1) instead of n(n-1)/2, in order to keep the model separate from the view, I think you got the idea.

Imagine that you want to design and develop a web software solution, and you want to organize your code to be maintainable and optimized when you add more features, which means adding more views and models, and you thought that you may use one of these architectural design patterns and unfortunately you don’t deeply understand why do you want to use them anyway, well, this is how you can think of ‘em.

You could simply project our simple solution, by replacing.

• Your models: with the left layer (Left nodes), represents models classes, for example, Users.php, Product.php etc…
• Your Views: with the right layer (Right nodes), represents the views files, for example, login.html, addProduct.html etc…
• Your octopus: the central hub, where you can define your logic that keeps your models and views connected to each other.

This is cool, isn’t it? we can deduce that this approach of understating this concept of model, view, octopus (MVO) is all about reducing and cleaning connections between models and views so we can keep tracking our software development process by adding new features i.e adding new views and models, and for sure you are free to add more than one octopus, all you have to do is following the rule that we’ve mentioned.

Examples of frameworks that using MVO.

• Laravel
• Symphony
• Angular
• Vue
• Backbone.js
• Ember.js
• ASP.net MVC

You can start playing with one of these to see the difference and the usability.

Conclusion

Let the octopus do the job, i.e use (n-1) instead of n(n-1)/2.

Think differently, Think out of the box.

Links

• Architectural design patterns.
• Model View Controller.
• Model View Presenter.
• Model View ViewModel.
• Separation of concerns.
• Graph theory.