Store - redux

A while ago I wrote about extending the Store in Greg Lhotellier's MVC-RS pattern, splitting it into a source and sink. A recent talk about Firebase I gave at my local CocoaHeads gave me the chance to revisit my initial approach, and I realised I was doing it all wrong.

I'm going to go back to the initial design and point out where I could have done things a little differently. To recap, I took the idea of the store, which sat between the model and persistence layers and extended it to any source of model data, not just the persistence layer. I further extended it to have more than one possible destination, not just the model layer. Then I rejigged the store to be the centre of this design, like so:

When I was creating some sample code for my presentation, I had a Generator object that was creating data, so it acted as the source. The store took the generated data and passed it to the sinks, one of which was Firebase, the others being the UI and the debug console. But things were beginning to feel a little... off. Like I was missing the point. This was my architecture:

I realised that I'd got a little carried away with the idea of extending the store to handle any and all sources and sinks of data, and it caused me to forget the problem that the store was solving, the serialisation from one form of data representation to another.  I wasn't extending Store to apply the solution to a more general problem, I was creating a solution to a completely different problem. I was creating a solution to data flow. What I was still calling Store was in fact a data flow coordinator.

In fact, my source was generating model data, and the sinks were all being passed the model. This meant at the Firebase sink I still needed to convert from the model to the Firebase representation, I needed a... Store. So I ended up with this:

Ok, many facepalms.

Once I realised this I was able to go back to my current project and really get to grips with what was data flow and what was store, and the refactor has been a great success. Where previously I had some data flow happening using source and sinks, while others were using NSNotification when the model changed, now all of my data flow is source and sink based. It's easier to follow in the code and is nicely separated, the responsibilities are well defined. 

To sum up, while I don't think it's accurate to say I completely misunderstood the concept of the Store, I definitely got kind of blinded by the data flow rather than the conversion between the model and the persistence representations.