Wrapping ManagedObjectContext

[eimantas]

I am making a CRUD application.

I have an environment that has a repository object that has MOC. I wonder if I am correct in my assumption that when returning objects from CD store I should convert them to simple DTOs in the Effect and return them to the reducer as simple structs (as to hide the dependency from CD). And should I do the reverse when accepting user input from views by accepting DTO into the Effect that later then converts it to instance of NSManagedObject. Same question applies to the object updates and deletes by object ids.

So basically I wonder if it's an accepted practice of converting DTOs to implementation-dependent objects (CoreData, SQLite, serialized json, etc.) in the Effects OR can effects expose the implementation-dependent types to the reducer and the state?

[roanutil]

If your repository object is working on a queue other than main, you'll want to use a struct model in TCA and contain NSManagedObjects to the repository. If your NSManagedObjects are equatable and you plan to only use the main queue, there shouldn't be a technical reason to require struct models in Effects.

But I would say it's far preferable to keep NSManagedObjects out of the Reducer, State and Actions. Do all that CRUD work on a serial background queue and use a struct model in all the TCA stuff.