0

I am trying to get my head into the Reactive world, and still find my understanding falling short when it comes to best practices. ReactiveCocoa seems to be used most often on the VC side of MVC. I was looking for a way to use it within the model.

My idea currently is to have a RACSubject property on my model objects called 'saveRequests' - when something changes in the model object it calls 'sendNext:' on its saveRequests property... basically marking itself as dirty.

In the AppDelegate I am subscribing to the saveRequests signal of my parent model object, and saving to disk on next signals (buffering every 2 secs to avoid overloading disk ops). This seems to be working, but I wanted to take it further by cascading the saveRequest signals.

I have a model object that owns an array of other model objects. When one of those objects triggers a saveRequest signal I would like the parent object to in turn trigger its saveRequest signal. I have this working by having the parent subscribe to each child object when it is added.

However, when an child model object is removed from the parent I want the parent to unsubscribe from any further saveRequests from the child - I understand it is only automatically unsubscribed when the child object is dealloc'd (which may not happen straight away if the child is being held onto by something else).

So, a few questions:

  • Is this even a sensible idea as a way for models to mark themselves as dirty and trigger persistence?
  • I have read that the RACSubject is probably not the best to use - should I use RACSignal instead, and why?
  • In order to unsubscribe from each of the child objects I need to use a RACDisposable, right? Is the only way to use the one that is returned when I subscribe to the signal, and in that case do I need to hang onto it in the parent object?
  • With regard to cascading the saveRequest signal, am I reinventing a square wheel here? There seem to be a lot of ways of using the RAC api - are there any better solutions that might meet my needs?

Thanks in advance - this Reactive thing is fascinating, but requires a shift in mindset, and seems very open to misuse if best practices are not followed.

Laurie

Loz
  • 2,198
  • 2
  • 21
  • 22
  • The "M" part of MVC specifically warns against a "smart model." – CodaFi May 31 '13 at 04:47
  • 1
    You have too many loosely questions squeezed into this single post. It would be better if you posted them with their respective contexts and made this one more focused. – allprog Jun 04 '13 at 13:37

1 Answers1

2

In the MVC paradigm your model is responsible for notifying listeners about its changes. Persisting the model is usually a coordinated action triggered by well defined conditions. If your model needs to be persisted on every change, then you should do that. I don't think there is best practice against it. Throttling and buffering is a good idea though.

John Reid has an excellent post about this topic. http://qualitycoding.org/mvc-tdd/ He basically explains how you can TDD (Test Driven Develop) a model-view-controller system. He uses notifications for getting updates from the model but in this respect there is a natural exchange to ReactiveCocoa. IMHO ReactiveCocoa is even better as it gives you an explicit way to handle subscriptions through Disposables which are not hidden state like the notification observation.

As to how you should implement it will highly depend on your model. For general persistence utilities you may look at the lightweight Github's Mantle https://github.com/github/Mantle or the core data based Magical Record https://github.com/magicalpanda/MagicalRecord.

allprog
  • 16,540
  • 9
  • 56
  • 97