This is the best explanation and great thinking. I was wondering why people recommended MV, besides blindly following what others are doing. This video shines when it has explained all the details behind it with a detailed comparison. Thank you for sharing! Great work!
Thank you, glad it was helpful. Developers are free to follow whatever architecture fits their project size, but blindly following something without technical comparison or having any reason is a bad approach to software engineering.
Great video! Congratulations! But I have a question. Should MV pattern makes sense only if you use the new @Observable introduced in iOS 17? Otherwise we'll have lots of problems in terms of basic principles, like you said in the video. I mean, if we use @Observable in our model classes it will resolve lots of the problems that the video raises, right?
Nice explanation buddy .. Awesome every time ... For this I thought, MVVM would be right option because that pattern for complex or large project as of now only Model is not capable of doing multiple things and that violates too. Why we used ObservedObject instead of StateObject ? Also can you please make one video On Custom Components in SwiftUI ?
If you are building one view model per view that's wrong approach because you can inject the view model into child views and get the job done using StateObject wrapper. I would also like to hightlight if you are creating viewModel per screen then the code will be duplicated across the app thus violating DRY (Don't repeat yourself) principle.
@7:40 i know this was for illustration but it seems like bad nomenclature. Why would Product have the functionality to getAllProducts? Product should just be a simple struct model/definition and the functionality to getAllProducts should probably be in something like a ProductService no? Also @11:40 I'm not fully convinced that the Model is a ViewModel even if it is similar. I remember watching Apple's wwdc video on data driving the app and while they didn't mention MVVM as an architecture they did emphasise on data being the 'source of truth' which is why Model is being passed around. Granted that doing it this way does seem like the View is going to be less testable than when abstracting the code to a VM. I'd say that more than architecture, it is important to design the system in a way that easily and efficiently allows us to write functionality as well as make it testable even if it involves using multiple architectures for different parts of the app rather than forcing a one size fits all architecture. Thoughts?
Agreed to what you said, that's exactly what the MV pattern proposes that is to have getAllProduct inside of a model. For small projects surely you can go with whatever you like but will it hold water for large enterprise apps? No What apple provides in their demo is just a proposal of how to achieve certain things but taking it word by word is wrong because enterprise apps are not demos that an engineer builds there are various complexities and challenges around it. There is certainly not one shoe fit all solution but keeping your design flexible to change around application volatility is the bare minimum you can do.
I reviewed the same approach it too has issues. Every solution has trade-offs but then if the trade-off is breaking basic programming principles then is it worth going that route? I leave that choice to the developer who implement that solution.
This is the best explanation and great thinking. I was wondering why people recommended MV, besides blindly following what others are doing. This video shines when it has explained all the details behind it with a detailed comparison. Thank you for sharing! Great work!
Thank you, glad it was helpful. Developers are free to follow whatever architecture fits their project size, but blindly following something without technical comparison or having any reason is a bad approach to software engineering.
Great video! Congratulations! But I have a question. Should MV pattern makes sense only if you use the new @Observable introduced in iOS 17? Otherwise we'll have lots of problems in terms of basic principles, like you said in the video. I mean, if we use @Observable in our model classes it will resolve lots of the problems that the video raises, right?
Nice Explanation Ravi bhai . BTW which tool did you draw the diagram ?
I use google slide for drawing diagrams for my presentation, they have everything that I need.
Nice explanation buddy .. Awesome every time ...
For this I thought, MVVM would be right option because that pattern for complex or large project as of now only Model is not capable of doing multiple things and that violates too.
Why we used ObservedObject instead of StateObject ?
Also can you please make one video On Custom Components in SwiftUI ?
The model violation has already been discussed from last 2 decades but still sad to see many influencers trying to preach bad practices.
I have a doubt, In my small to medium app, there already are around 10 VMs, it grows bigger, how it will scale up like it will have 100s of VMs?
If you are building one view model per view that's wrong approach because you can inject the view model into child views and get the job done using StateObject wrapper. I would also like to hightlight if you are creating viewModel per screen then the code will be duplicated across the app thus violating DRY (Don't repeat yourself) principle.
@7:40 i know this was for illustration but it seems like bad nomenclature. Why would Product have the functionality to getAllProducts? Product should just be a simple struct model/definition and the functionality to getAllProducts should probably be in something like a ProductService no? Also @11:40 I'm not fully convinced that the Model is a ViewModel even if it is similar. I remember watching Apple's wwdc video on data driving the app and while they didn't mention MVVM as an architecture they did emphasise on data being the 'source of truth' which is why Model is being passed around. Granted that doing it this way does seem like the View is going to be less testable than when abstracting the code to a VM. I'd say that more than architecture, it is important to design the system in a way that easily and efficiently allows us to write functionality as well as make it testable even if it involves using multiple architectures for different parts of the app rather than forcing a one size fits all architecture. Thoughts?
Agreed to what you said, that's exactly what the MV pattern proposes that is to have getAllProduct inside of a model. For small projects surely you can go with whatever you like but will it hold water for large enterprise apps? No
What apple provides in their demo is just a proposal of how to achieve certain things but taking it word by word is wrong because enterprise apps are not demos that an engineer builds there are various complexities and challenges around it. There is certainly not one shoe fit all solution but keeping your design flexible to change around application volatility is the bare minimum you can do.
Rebeloper tried to tackle this problem with a pattern.
I reviewed the same approach it too has issues. Every solution has trade-offs but then if the trade-off is breaking basic programming principles then is it worth going that route? I leave that choice to the developer who implement that solution.