What is correct in your opinion regarding the creation and handling of models in an application let's say using MVVM, or even an MVC design pattern?

I will try to illustrate the situation I see at my company in an iOS Application,

  • We have a couple of tabs in our application and for each tab we create the models needed to be used on the flow of that tab.
  • One of the tabs allow the user to see a list of Events for a given week and upon clicking on one of the events he has access to the details of that event and also the option to favorite the event in case he wishes to do so.
  • There's another tab in the application that shows only the favorite events.
  • We have a model to handle events called let's say EventModel that can retrieve all the events for a given week, knows how to favorite events, unfavorite events, delete and so on.

The goal is whenever a user favorites an Event from the events list flow I want the FavoritesTab to reflect the new favorite being added immediately, in other words I want to keep the 2 instances of the EventModel in sync.

How it currently is:

We use Combine publishers to reactively send updates from model to ViewModel, and We use Coredata's fetchedResultController to fire the publishers in our models and send update to the viewModel. So the current setup works because we are relying on the Coredata Framework to send updates however I feel like it is not quite correct because we are depending on the database technology to sync the models and if we change Coredata to other framework it might break our current application simply because the next DB solution we decide to use might not behave the same way as coredata does so our Model will break whilst according to everything I have learned so far Models shouldn't care about details, they shouldn't care which Cache technology I use but in our case it feels like they are dependent on Coredata to work properly.

So trying to summarise the current setup:

Events Tab holds EventsView listen EventsViewModel uses EventsModel (instance 1)

Favorites Tab holds FavoriteEventsView listen FavoriteEventsViewModel uses EventsModel (instance 2)

They are kept in sync by Coredata since that's tech we use for database.

My question is, Is it correct or advisable to have more than one instance of the model in the whole application when we come from different flows? Should it be a singleton? Should We create one instance in the application root level and pass this reference down without ever creating a second instance?

Another question is, How do you keep models in sync? Maybe having a single model would solve the problems of syncing since I could (after adding some thread safety on Model layer) just send a publisher event and now since I have only one instance everyone depending on that model would be updated no problems.

I just would like to ask what is your take on this do you think it is a correct approach delegate the sync work to the persistence/caching strategy? or should it be internally handled by the models?

I feel somehow that our models are too dependent on Coredata but if we remove the Coredata dependency the multiple instances create now a sync problem.

I appreciate any inputs/opinions you have, Thank you in advance.

1 Answer 1


Having only one instance of your model is often desirable for exactly the reasons you mentioned, and the approach of using some "publisher event" to update all views is pretty standard. It can be implemented by using what Fowler calls an Identity Map, and it solves not only syncing issues, but can also reduce the number of database roundtrips.

One downside is that implementing an identity map may be more development effort than simply working with two model instances, and sometime this additional effort isn't actually worth it. Moreover, have in mind sometimes you want to create temporary duplicate instances of some model objects, for example for trying out some changes first before saving them into a database or before making them visible in all views. In general, you should be aware of potential side effects when different parts of your program can not only display, but also change the very same object as part of independent use cases.

So in short, it depends. There is no way around analysing your specific situation and think about what you are doing. As always, there is no "one-size-fits-all" solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.