search

M-I-N / NimbleSurvey

0 stars 0 forks source link

[Question] MVC design pattern choice concern #10

Open minhnimble opened 2 years ago

minhnimble commented 2 years ago

Issue

I have a major concern about the fact that you are using MVC as the main architecture for the application. Why do you choose to implement the application using MVC and are you aware of the advantages and disadvantages of the MVC architecture?

M-I-N commented 2 years ago

First of all, I want to point out that the architecture I followed is not a plain MVC. The preparation and presentation of data heavily depend on Service, Adapter and ViewModel. Though there are not many ViewModels in the source code as of now because of the scope and requirements of the assignment, there will be many more of them as the business logic grows in future.

I happen to find out that MVVM shines in terms of project architecture when used with Reactive Frameworks. Unfortunately I don't have the fortune of using reactive frameworks in any of my professional project yet. So I can't leverage the power of MVVM. But as I consider the MVVM and Reactive Frameworks as tools and they are not rocket science, I think I can adapt myself to use the tools going along with a project and a team using these technologies.

Besides, with the evolution of Combine framework and async/await pattern we, the dev communities around the world, are expected to experience new shifts in how we design and architect our solution. So we are into continuous learning stage.

I'm quite not sure why you are assuming the architecture to be a traditional MVC which suffers from not having separation of concerns. The MVC embraced by Apple may have the problem of assigning too many responsibilities to the view controllers. But the MVC architecture itself is not to be blamed for the fact that we tend to ruin the codebase.

For me, no architecture is bad if it is done right. And no pattern is good enough if it is used in the wrong way.

To the best of my knowledge that I have acquired, I think MVVM is an extended version of the typical MVC. The MVVM pattern presents a better separation of concerns by adding view models to the mix. (Supporting articles to my claim: here, here). MVVM is a derivation from MVC (Articles supporting this claim: here, here).

Here we try to take out the burdens off of view controllers. We tend to offload as much responsibilities as we can to some other objects. Like:

There are many more considerations for assigning these responsibilities to the objects they are best suited for.

Lastly, I want to point out that I tried to coordinate as well as accommodate as many principles of SOLID design patterns as I can. Because we may encounter many architecture patterns as we advance in this software development industry, but the SOLID principles are there to stay.

minhnimble commented 2 years ago

Hello @M-I-N, thank you for your detailed and quite interesting response! 🙏 Regarding your comments, I would like to reply to them as follow:

First of all, I want to point out that the architecture I followed is not a plain MVC. The preparation and presentation of data heavily depend on Service, Adapter and ViewModel. Though there are not many ViewModels in the source code as of now because of the scope and requirements of the assignment, there will be many more of them as the business logic grows in future.

→ Looking at the only ViewModel class - SurveyItemViewModel.swift that you currently have in your implementation, just to confirm, do you mean that this is the ViewModel that is in charge of the business logic as you mentioned?

https://github.com/M-I-N/NimbleSurvey/blob/c7575c9d61b58f84cd7124cd99f601633de2d22d/NimbleSurvey/ViewModel/SurveyItemViewModel.swift#L1-L29

By the way, from a standard approach to implementing the MVC architecture in Swift, aren't Service and Adapter needed by default? Or do you mean that for the MVC architecture, all Service and Adapter handling code should be put directly in the Controller layer? 🤔

I'm quite not sure why you are assuming the architecture to be a traditional MVC which suffers from not having separation of concerns. The MVC embraced by Apple may have the problem of assigning too many responsibilities to the view controllers. But the MVC architecture itself is not to be blamed for the fact that we tend to ruin the codebase.

For me, no architecture is bad if it is done right. And no pattern is good enough if it is used in the wrong way.

→ Isn't it quite clear that from your submission, the business logic code is being put directly inside the ViewController alongside with all the UI setup code?

It is quite interesting that you are aware of the disadvantages of the MVC architecture and still opt to go with it. Just to clarify again, MVC is a good option for you as long as it is used in the "right" way, is that correct?

Then I am a bit curious that when there is more complex logic introduced in a single screen, how can you use it correctly to avoid adding too many responsibilities to the view controller? and how we can properly write tests for each business logic flow in one screen since the logic and UI implementation are not properly decoupled in the view controller? 🤔

Lastly, I want to point out that I tried to coordinate as well as accommodate as many principles of SOLID design patterns as I can. Because we may encounter many architecture patterns as we advance in this software development industry, but the SOLID principles are there to stay.

→ I agree with you on this idea, but following the principles of SOLID design patterns alone doesn't help to solve certain problems of the MVC architecture. That is why new architectural design patterns are born to solve them, and you actually mentioned some of the advantages of the MVVM architecture as a comparison as well.

M-I-N commented 2 years ago

First I'll comment to some points you asked. Then I have a question at the end.

→ Looking at the only ViewModel class - SurveyItemViewModel.swift that you currently have in your implementation, just to confirm, do you mean that this is the ViewModel that is in charge of the business logic as you mentioned?

Yes. This is where the business logic goes. The business logic regarding presentation and transformation of the data. But as of now, there isn't many because of the simplicity of the assignment.

By the way, from a standard approach to implementing the MVC architecture in Swift, aren't Service and Adapter needed by default? Or do you mean that for the MVC architecture, all Service and Adapter handling code should be put directly in the Controller layer? 🤔

No, actually these components are not default in the standard implementation of MVC, at least in the world of iOS development. The article you shared also addresses this issue and how we can avoid the many responsibilities of View Controller.

And I didn't mean it anyway that in MVC, all these codes need to be stuffed into the controller layer. I was trying to emphasise that we, as developers, tend to put these there. That's how we get messed up in the long run and left with the well known joke of massive view controller ios.

Now my question is about this part of your comment.

→ Isn't it quite clear that from your submission, the business logic code is being put directly inside the ViewController alongside with all the UI setup code?

As I have already mentioned that I'm not well versed in any Reactive Frameworks yet, I am not aware of any way to avoid this minimal configuration of the business logic in the view controller in an MVVM setup? Would you mind point me with a direction preferably to any article or resource or any code examples? I am super curious to know how this is avoided in MVVM pattern implemented without reactive framework.