Hi community,

over and over again I find issues in updating detail or cellviews in Core Data apps.

One of the archtictures, that even Paul is recommending is:

1. every (at least most) of the views have their corresponding ViewModel
2. the ViewModel for the respective view is an extension of the View
3. the parentview provides the data information for its shildview in the initializer for the childview (often in a ForEach loop)
4. the childview then creates a viewModel as an @StateObject and hands the data to this viewModel which uses the @Publish wrapper to inform the view about changes.

Here comes the problem: The viewModel itself must identify changes, which might be created in an addDataView or editDataView and save these data to the context. Usually the parent view might act as a delegate to a controller that will be informed about changes in the context or in CoreData. However the patentView has no access to the viewController of the childview and even if it had, it is not a good architecture, that the parentView hands over the data to the childView, that forwards the data to its viewModel and somewhere later the parentView updates the data directly in the child's viewModel.

I tried to draw this relationship, but it is a nightmare.

I have now implemented it with another architecture:

1. the patentViews ViewModel creates the ViewModel for its child
2. this ViewModel as a @Published property is handed over to the childView
3. the responsibilty for updating this viewModel starts and stays with the parentView
4. when the parentView updates its child's viewModel, the childView is re-rendered

This architecture is much less complex and seems more logical to me. On the other hand I have not yet seen anybody on HWS, Udemy, StackOverflow or other videos, that recommend this architecture.

What do you think about these two alternatives?

@MrSpock finds CoreData to be....wait for it................illogical!?

over and over again I find issues in updating detail or cellviews in Core Data apps.
...snip... many architecture woes.....snip....
I tried to draw this relationship, but it is a nightmare.
What do you think about these two alternatives?

Honestly, I didn't take a close look at your descriptions or the written description of your various paths for updating data.

But what do I think?

Like you, my head ached trying to understand CoreData and its nuances. (Why did CoreData return Sets, rather than Arrays for example?) And yes, the ObservableObjects and separate CoreData modeler interface were often at odds with each other.

I think the warts and rough edges of CoreData, @Published, view models, and related topics were hot topics in Apple's secret planning sessions for years. Their solution? Dump CoreData and go with SwiftData.

To be honest, I read your message but I won't be attempting an answer. The first step I'd recommend is to abandon CoreData and try to reorganize your solution around SwiftData. Many of your issues may simply evaporate allowing you to again refocus on your solution.

Many of us are trying SwiftData now. You have allies here who can share their new successes with SwiftData to over come CoreData and SwiftUI issues. If you stay with CoreData, good luck!

Fascinating :-)

Thank you Obelix for your thoughts. I will definitely look into SwiftData very soon and I also see that it will still take some time until SwiftData supports everything that CoreData has on board afer severall years of development.

At the same time I did in fact not struggle with CoreData, but with the software architecture. I do understand that reading my topic above and trying to understand the difference between the two approaches is time consuming. So I try to break it down to a single question.

Who should "own" the data that a view should present on the screen?

Should these data be owned by the view itself and the view takes the responsibility to update the data accordingly, even if he hands the data over to a ViewModel, that it owns? Or should the data be owned by the parentView's ViewModel? Once I spent some hours(!) thinkimng about it, the second solution is the better one and the more "logical" one :-)

My code gets less complex and keep the data current is now no longer the responsibility of the view, but of the ViewModel.