.jpg)
When working on a software development project, there are several avenues of design to venture down, some are more detailed but require more time and money to make, while some others can get you a functional version of the product relatively quickly in a cheap and cheerful way.
While both versions have a similar end result in that they look and function how they are expected to, the cheaper version usually causes issues with development further down the line.
For example, a fun way of thinking about the differences is to imagine two identical cars. Everything about their exteriors are the same, however one is twice the price of the other. This is because even though both cars look the same, the internal components are very different. The engine in one car is far superior with much greater horsepower and a higher top speed. Therefore, while the two cars look similar, they have different values because one had far more time, effort and consideration put into it while it was being built, making it the better car overall.
When designing a software project, it is important to consider that a good design fundamentally has to be:
Whereas a bad design will not have these core elements; cheaper versions of a development project will usually be badly designed because they have not had the necessary resources or attention paid to them. As previously mentioned, they will function fairly well, but in the future if the software has to be updated or edited, the simple design will make changes very difficult to implement.
In comparison, more expensive versions with more detailed architecture will ultimately be easier to change and adapt as they were designed with this in mind. This is why it is so important to take the time to develop a project fully rather than saving resources by cutting corners. A cheaper version is a good proto-type but the real thing should have more depth. To have a better understanding of the differences in architectural design, let's examine some of the architectural patterns that can be used when developing a project and how they differ.
Christopher Alexander introduced the idea of design patterns in architecture with his book “The Timeless Way of Building” in 1979. However, just over a decade later, experts realised they could apply Alexander's ideas to software development and began to outline how to implement this. Previously in software development, everything had to be manually coded from the top down which involved an immense amount of repetition, but the release of ”Design Patterns: Elements of Reusable Object-Oriented Software” by Gamma, Helm, Johnson, & Vlissides (1995) aka “The Gang of Four”, changed all of this.
This book popularised the idea that the design patterns originally outlined by Alexander could be utilised in software development. They detail the concept of object-oriented software, presenting solutions to commonly occurring design problems and removing the need for developers to rediscover design solutions for themselves. They outline designs that are flexible, elegant, and most importantly, reusable! All of the examples are based on real-world problems and systems and have demonstrations of how to be implemented.
There are now countless designs that can be used and implemented by software developers but we want to focus on some of the most important architectural patterns and will discuss the key four.
One of the most fundamental patterns described in “Design Patterns”, the grandfather of all other architectural designs frequently used by developers, is the Model/View/Controller (MVC) design. This design divides the programming logic into three separate elements in order to separate internal representations of information from the ways the information is presented and interacted with by the user.
Firstly we have the View, this is what the end user sees on their screen and interacts with, it is responsible for rendering the User Interface (UI).
Secondly, the Controller sits beside the View architecturally and works between the Model and the View, it takes the user input and will request the Model for data from the database or from some online services, then it will pass this data into the View.
Finally we have the Model, this is responsible for retrieving and manipulating the stored data. It is important to note that in this design, the View also has direct access to the Model though this can cause security issues and performance costs. The MVC design prevents repetition and creates a solid structure for programming an application. If developed and used correctly, the structure will mean that if you change something it filters down through the model, removing the need to manually change all of the code.
Another pattern that is frequently used is Model/View/Presenter or MVP, which is a derivative of MVC. In this architectural pattern the Controller is replaced by the Presenter, this acts as a middleman that has almost all presentation logic pushed through it to go between the Model and the View.
This MVP design has two variations, the “Passive View” and the “Supervising Controller”. In the more commonly used “Passive View”, the View contains almost zero logic and does not interact with the Model directly at all. There is no direct data binding, instead the View exposes functions which the Presenter uses to update the view according to the data. All data is managed in the Presenter and not the View.
However, in the “Supervising Controller” design, the Presenter handles user gestures and passes the Model to the View so it can bind via data binding, meaning there is an interaction between the Model and the View in this variation.
The use of data binding reduces the amount of code required but there is also less testable surface, unlike in the “Passive View” where there is maximum testable surface as the View and Model are cleanly separated. Other than the variations outlined, the Model and View both function in mostly the same way as in the MVC pattern.
.png)
Now for the Model/View/View-Model design created in 2005 by John Gossman, an architect at Microsoft. In this design, the Model contains the data model along with business and validation logic.
The View element remains the same, it makes up the User Interface and communicates solely through the View-Model while having no direct communication with the Model itself.
The View-Model is the ‘interconnecting chain’ between the View and Model components. The main function is to process the View’s logic and provide data from the Model that the View can process easily.
MVVM differs from MVP as multiple views can be mapped to one View-Model, whereas the MVP only has one-to-one mapping between the Presenter and the View. Moreover, the main approach to update the View is based on data binding, so the View doesn’t expose any function to the View-Model, but just ‘observes’ the data manipulating it and updates itself accordingly.
Let us move onto View/Interactor/Presenter/Entity/Routing design, or VIPER, a more modern evolution of MVP. As with the other designs mentioned, each component is responsible for a separate function, some are similar to previous designs and others are new to VIPER.
The View component remains the same, acting as the User Interface. Then there is the Presenter though this has limited capabilities; it receives updates from the Entity but does not send any data to it. Next, the Interactor is the system component that corresponds with the Entity, receiving input from the Presenter about changes in the View, it then contacts the Entity and returns information to the Presenter to command the View. The Entity consists of objects controlled by the Interactor. Finally the Routing is responsible for navigation between all screens and for routing.
The VIPER design solves many difficulties developers previously faced with the MVC, MVP and MVVM patterns as the well distributed design allows for tests of all functionalities. It is largely used to build iOS apps, but its concept can be applied to more development fields.
No single design is perfect, MVC, MVP and MVVM all have close connections that make updates tricky to develop and testing them afterwards a slightly more difficult task. Meanwhile, though VIPER solves this issue of connectedness and has high flexibility and testability, it also has many nuances that are difficult to generate. In each project, it is up to developers to decide which design will work best for them and for any future updates or developments they may want to make, it’s important to keep a good balance between required features and code complexity in order to avoid using architecture designs that are a clear overkill for the final product that we want to build. Going forward, take into consideration the elements that are important for your project to possess and how you can best develop and implement these.
Geeks for Geeks 2018, accessed 5 January 2020, <https://www.geeksforgeeks.org/mvc-design-pattern/>
InformIt 2009, Pearson, accessed 6 January 2020, <http://www.informit.com/articles/article.aspx?p=1327762>
Patrick Kusebauch 2016, accessed 5 January 2020, <http://www.kusebauch.cz/mvpc-the-difference-between-presenter-and-controller>
Safari (n.d.), O’Reilly, accessed 6 January 2020, <https://www.oreilly.com/library/view/learning-javascript-design/9781449334840/ch10s09.html>
Todd Snyder 2007, Infragistics, accessed 6 January 2020, <https://www.infragistics.com/community/blogs/b/todd_snyder/posts/mvc-or-mvp-pattern-whats-the-difference>
Wania, C. E. (2015, November). Investigating an author's influence using citation analyses: Christopher Alexander (1964-2014). In Proceedings of the 78th ASIS&T Annual Meeting: Information Science with Impact: Research in and for the Community (p. 29). American Society for Information Science.
.png){kind=small}