Exploring UI Design Patterns: MVC, MVP, and MVVM

In this video, join me as I dive into the exciting world of UI design patterns for mobile development. We will explore MVC, MVP, and MVVM, specifically tailored for the presentation layer of your app. Discover how these patterns enhance modularity, testability, and readability of your code. I will discuss the challenges and benefits of each pattern, comparing their characteristics. Whether you're a beginner or an experienced developer, this video will provide you with valuable insights into choosing the right architecture for your mobile app.
Don't miss out on the recommended GitHub repository packed with helpful resources: github.com/onmyway133/awesome...
Chapters:
0:00 Intro
0:40 Traditional MVC
1:45 Apple MVC
3:52 MVP
5:57 MVVM
8:28 Helpful resources

[@vighneswarmulaga9088]

An insightful comparison among MVC, MVP, MVVM. Thanks Andrey

[@andrey_tech]

Cheers!

[@abdorizak]

Great explanation thanks Andrey

[@andrey_tech]

Thanks, I appreciate it 👍

[@oneukrainianman5300]

Nice video Andrey, a lot of things told similarly as i understand them. But seems I have some misunderstanding.
2:55 "One reason of Massive VC problem is - ViewController is thightly coupled with the view .... ViewContoller becomes delegate and dataSource for everything.". If we think of UIKit paradigm, it's always tightly coupled, as we simply cannot avoid VC, as it initializes our custom UIKit components which we design in separate files. As well as we cannot avoid VC being delegate and dataSource for everything.
3:18 "Tight coupling between VC and V". VC always has its custom Views as a properties, otherwise VC will not be able to manage properties of V?
So, I think things you've told is not reason of "Massive VC", as we have absolute same behaviour of VC(described above) in MVVM, VIPER or anything else.
What can really make VC massive is a large presentation logic, and other logic which is not related to business(preparing data before get/post/put/delete in M, filtering, formatting, validation etc.), as we shouldn't keep it in M, and C is more appropriate place for it.
Maybe I'm wrong, and misunderstood your point. What do you think?

[@andrey_tech]

Thanks for the comment. With all due respect, I disagree. You don't need to store and prepare data for UI in the ViewController itself, you can do it in presenter, for example. Take a look at ViewControllers code in this example MVP repo - github.com/powerwolf543/Swift-MVP-Sample

[@oneukrainianman5300]

@@andrey_tech Thanks for your answer! As you mentioned in your answer, "prepare data for UI" is indeed happens in Presenter, as it is Presentation logic. The thing is: in MVC we don't have Presenter, so Presentation logic belongs to Controller. If to be honest, I misunderstood what are you disagree about. In my comment I reffer to parts of video whre you talk about Massive View Controller problem, and not MVP part, where everything sounds correct to me.

[@andrey_tech]

Ok, makes sense!