Migrating SwiftUI MVVM App to MV Pattern

Great video, my last two applications are using this approach, only after time when they become too large I need to refactor in multiple models, like you are suggesting here.

i got recommendation now but good explanation....thanks for the knowledge

Coming from React background, where we have context providers, this seems more natural way to code in SwiftUI instead of having a ViewModel for every View. I can just have a global model for my context and pass it down as an EnvironmentalObject which suits me just fine. And I can access the model/context methods/functions from any child view that is bound to the environmentObject. Thank you for explaining the key difference between MVVM and just MV which was driving me crazy as so many other videos lack the coding example you've shown.Thank you!

Hi @azamsharp Azam,
I hope you will be fine and doing great things,
I have question about the Aggregate Model, you are saying that we need to use only one model, and not use viewModel for every class.
Okay I accept that, but with your approach we are killing the SOLID principles, With approach you told us in the tutorial, Our Aggregate Model class has more than one responsibility, if we need to check some other things or bring things from the Server than we will add that these things in the Aggregate model again, and it will be the another responsibility of that Aggregate Model.
My question is how you will justify with the SOLID principle "S" that stands (Single Responsibility Principle)?
I hope so you will answer a good and healthy way.

ScoobyDoo.swift has entered the chat

nice

Hi Azam, thank's for the video, is really well explained and thought. Hope will contribute to get more people out of the trap of MVVM.

Your aggregate models seem a lot like what Siesta was doing back in the days of UIKit, basically a resource based networking approach where each collection of the backend would be modeled as a stateful observable resource able to retrieve itself and shared within the app so UI is kept in sync.

I would suggest taking a look, I've not used it yet (I discovered it recently) but seems like an excellent approach for those who still need to use UIKit and could be useful as inspiration for those who plan to rely on SwiftUI basic SDK instead of intrincated architectures.

About the ActiveRecord pattern, have you considered using protocol extensions for automating fetching on the entities? With protocol extension + ObservableObjects you could easily do what Siesta does on SwiftUI. Regards!

Azamsharp, what is the tool that you use to mark when you explain?

Great video! Can you help understand does this approach violate single responsibility principle from SOLID? I see Apple is making similar models in their sample SwiftUI apps, but I am still confused and don't understand if this is safe.

I like it! I'm going to give it a try in my current project, I've been frustrated recently with MVVM

AddOrderscreen doesn't require loadorder method. But it can access that method too..

In our application we called the aggregate class "Provider". The provider is tight to a domain. Examaple, everything related to "client" will be placed there. The state are publishers. The publishers on the provider will be used by our ViewModels. We use viewModels because for us the purpose of a viewModel is to manage the view only, thus is necessary.

I have a concern with this approach. Lets say we have 3 views- ViewA, ViewB and ViewC. We will be using one Aggregator Model for all of these views according to your idea. Lets assume all the views need different properties to load into them. So our Model has all those different published properties. In that case, ViewA will be able to access the other properties needed for ViewB and ViewC and vice versa. And in my opinion, this is a bit unnecessary, after all we encapsulate things to make them hide from the outside world. So ViewB should not know anything about ViewA or ViewC unless they are connected somehow. I hope you clear these things

Using extensions of your base model could let you setup “domains” for functionality on larger projects. Not an original thought but one nonetheless.

This video literally came out in the perfect moment!! Thank you a lot! Do you by any chance have published the project in a public repo?