Open discussion- Application Architecture design patterns
“Live as if you were to die tomorrow. Learn as if you were to live forever.”
We at Jio, ran the iOS community. We have got numerous amount of interaction from the different teams of Jio through our last open session discussion. So we have decided to continue with some more interested topic to get huge amount of response from the developers of Jio.
Here, I have again come up with some interested topic that all developers love to integrate in their project. Today, I am going to start my discussion by giving a brief idea of the topic “Application Architecture design patterns”.
Whether you are developing any of the software programs related to any of the technologies, the success of the project hing on how well the developer can meet the project requirement. For larger project, there could be a team of developers that must work together to achieve their goal.
Developing such complex project is one of the main reasons why Design Patterns initially introduced. Design patterns are solutions to software design problems that occur consistently in real-world application development. These patterns present a reusable framework of designs and interactions of objects.
Today, I have set the specific agenda through which we can interact with the different teams of Jio. So I am going to brief you how the developers of Jio works with different architecture and design pattern.
Followings are the agenda of our discussion:
- Brief on MVVM/MVC/MVP/VIPER
- Pros and cons of using each of them
- Run down on what each team in Jio prefers!
- Declarative Programming, should we set our sail for this!
- How many of you agree that “One project can/should have multiple architectures”
- How many feel that we should follow “one codebase, one architecture”
Now I am sharing mine as well as teams point of view on the above agenda.
Brief on MVC/MVVM/MVP/VIPER
This is a huge topic to discuss, I will give you some brief of the different design pattern.
MVC design pattern is widely used as part of iOS application development. This pattern has 3 basic fundamental classes that we have to take care in our development. i.e Model, View, Controller.
MVVM design pattern on the other hand, developers are moving toward this as it is available with some more optimised way from MVC. MVVM stand for Model, View, View-Model. It supports two-way data binding between View and View-Model. This allows automatic propagation of changes, inside the state of View-Model to the View. Generally, the View-Model utilizes the observer pattern to inform changes in the View-Model to the Model.
MVP design pattern is similar to the MVC pattern. It is derived from MVC pattern, wherein the controller is replaced by the presenter. This pattern divides an application into three major aspects: Model, View, and Presenter.
VIPER design pattern, Mostly like MVP or MVC, It follows a modular approach. One feature, one module. For each module, VIPER has five different classes with distinct roles. No class goes beyond its sole purpose. i.e View, Interactor, Presenter, Entity, Router.
Apart from all the above design patterns, one of our team is using Builder design pattern. So as per them, this pattern will simplify more complex object with different object representation. So that the same construction process can create different representations of the object.
Pros and cons of using each of them
For this agenda, We got different views from different teams. Every patterns has their own advantages and disadvantages. Depending on the requirement and use cases of the project, We have to choose the design pattern to build the application architecture.
MVVM pattern over MVC has more certain flexibility to maintain our code. As in MVC, Our controller become more complex as we go ahead in the module. So MVVM serves that problem by modularising the features by giving the responsibility to the different class.
One another advantage of MVVM over MVC, It is better to write the unit test cases in MVVM because of every class has their own responsibility.
MVVM also has certain disadvantage like, It is very difficult to maintain different view model. Suppose you have an application which has some bussiness logic which is in business view model and obviously there is some UI component which drive our UI using view model. If our application goes bigger, It become little complex to handle different view model.
Run down on what each team in Jio prefers!
In Jio, Different teams have chosen different architecture depending on application use cases. Most of the teams follow MVC and MVVM design pattern.
Some teams also follow MVVM with clean architecture. Some also follow Builder design pattern.
So it purely depends on the use-cases of the application.
Declarative Programming, should we set our sail for this!
World is moving toward this nowadays. As a part of iOS 13 and above, Swift UI SDK supports the declarative programming. Every developer wanted to start with and enhances the skills on this.
Before we move more on this, We have to identified the difference between Imperative and Declarative programming.
Imperative programming is like HOW the function will work? where in Declarative programming is like What the function can do?
It is said that declarative programming can be used to achieve our goal because one of its basic concepts is describing the intentions of developers. Furthermore, if we write our code with a declarative way, we are going to obtain really great separation of concerns and therefore the testability will be brought. Overall, declarative programming is a helpful thought and it is worthwhile to give a try.
For now, Swift UI support is only from iOS 13, We as a developer have already started learning those area but it is a very difficult to integrate in existing project which has support from earlier OS. Difficult to maintain 2 code base on OS version.
How many of you agree that “One project can/should have multiple architectures”
As per my understanding, As a developers, We can not stuck with one technology. We have to learn a new technology every time when it comes. It will always give you a better way to handle your existing code.
So some of the teams think of one project should have multiple architectures. Reason behind this is we can achieve multiple goals in different ways and we can say it a better way.
How many feel that we should follow “one codebase, one architecture”
If we have an issue with code handling or something of sort of developers in team we can go with one common architecture in the project.
Advantage of this is, We do not have to handle the code with multiple architecture. Code stability is also maintained with this.
So in our today’s session, We have covered all the above agenda in a detailed way by having support of multiple teams of Jio.
Thanks to Dalee Tharayil for supporting and encouraging for this.
