Core Data is not an architecture, is just a database manager. MVVM is very important when we have medium and big projects, in this case we would have views sharing the same model, so we need an abstract layer to resolve functionality rules, also to avoid replicating changes in views, in case there is any change in properties.
You're right and I don't think I said that CoreData is an architecture - of course it isn't. As you heard in the video, this is just about my experience in indie projects. I totally agree that larger codebases (with multiple contributors) should consider other architectures. But I don't think that MVVM is always the solution - other great architectures likes VIPER or TCA also exist and have their usecases. Thanks for commenting & keeping the discussion going 💪
Where does he say that Core Data is an architecture? And no, Core Data is NOT "just a database manager". It's much bigger than that. It's right there on the tin: "Core Data is an object graph and persistence framework"
Okay Flo, good point. But image a situation where you have a super-extra hard request from CoreData with aggregate funcs and etc which can be repeated many times, so will you write the same code every time? Also most of developers would create CDService which would be protected by a protocol and use it within the ViewModel. In this case VM acts like a facade. To sum up, using CD in View is a bad idea, imho.
Hey Kaspar, thanks a lot for chiming in with the discussion! > But image a situation where you have a super-extra hard request from CoreData with aggregate funcs and etc which can be repeated many times, so will you write the same code every time? Since this video is about my experience, I can only say that none of my apps have such requests, so I can't really say anything regarding that. > To sum up, using CD in View is a bad idea, imho. I don't agree with this part. What about an app that is so simple in the logic side, that the ViewModels would only have one function? Wouldn't they then just be overhead & slow down development & maintainability? Also, if @.FetchRequest is a bad idea, then why was it added by Apple? I believe that @.Binding, @.FetchRequest and of course @.State clearly show, that Apple isn't opposed to having data & logic as part of the Views. Heck, why would buttons have a closure for an action, if it's such a bad thing to have logic in Views? I believe there are certainly apps where a CoreDataService or ViewModels make sense, but definitely not for every app.
Get instant access to ChatGPT anywhere on your mac: MacGPT.com
Core Data is not an architecture, is just a database manager.
MVVM is very important when we have medium and big projects, in this case we would have views sharing the same model, so we need an abstract layer to resolve functionality rules, also to avoid replicating changes in views, in case there is any change in properties.
You're right and I don't think I said that CoreData is an architecture - of course it isn't.
As you heard in the video, this is just about my experience in indie projects. I totally agree that larger codebases (with multiple contributors) should consider other architectures. But I don't think that MVVM is always the solution - other great architectures likes VIPER or TCA also exist and have their usecases.
Thanks for commenting & keeping the discussion going 💪
Where does he say that Core Data is an architecture?
And no, Core Data is NOT "just a database manager". It's much bigger than that.
It's right there on the tin: "Core Data is an object graph and persistence framework"
Core Data is a integer
Okay Flo, good point. But image a situation where you have a super-extra hard request from CoreData with aggregate funcs and etc which can be repeated many times, so will you write the same code every time? Also most of developers would create CDService which would be protected by a protocol and use it within the ViewModel. In this case VM acts like a facade. To sum up, using CD in View is a bad idea, imho.
You can always use extensions on the model classes and create FetchRequests inside the extensions and return it.
Hey Kaspar, thanks a lot for chiming in with the discussion!
> But image a situation where you have a super-extra hard request from CoreData with aggregate funcs and etc which can be repeated many times, so will you write the same code every time?
Since this video is about my experience, I can only say that none of my apps have such requests, so I can't really say anything regarding that.
> To sum up, using CD in View is a bad idea, imho.
I don't agree with this part. What about an app that is so simple in the logic side, that the ViewModels would only have one function?
Wouldn't they then just be overhead & slow down development & maintainability?
Also, if @.FetchRequest is a bad idea, then why was it added by Apple? I believe that @.Binding, @.FetchRequest and of course @.State clearly show, that Apple isn't opposed to having data & logic as part of the Views. Heck, why would buttons have a closure for an action, if it's such a bad thing to have logic in Views?
I believe there are certainly apps where a CoreDataService or ViewModels make sense, but definitely not for every app.
is your core data example as github repo available?
Not right now, since I figured that such a little amount of code wasn't worth putting on Github 😅
It’s a state object, the clue is in the name that it is not designed to be a view model