CoreDataStack interface should be a protocol for easier mocking about coredatastack HOT 3 CLOSED

@lyricsboy is something like this what you had in mind?

cc19a97

from coredatastack.

I like the separation of the different specializations into protocols. There are a few things we might consider here:

First, how does a "user" of CoreDataStack think about this and use it? Do they talk to a single interface, or an amalgamation of them provided by these protocols?

As one might look like:

let coreDataStack: CoreDataStack

Where CoreDataStack could be a protocol instead of a concrete type, such as:

protocol CoreDataStack: ThreeTierStack, SQLiteBackedStack, BatchOperationStack { ... }

As many, perhaps:

let coreDataStack: protocol<ThreeTierStack, SQLiteBackedStack>

For mocking/faking purposes, in general I want to be able to have as simple an interface as possible that I can stub out.

But for CoreData land and testing, it might be more sensible for me to be able to have a dependency (of a protocol type) that could be satisfied by either a SQLite stack (for production use) or an in-memory one (for testing). It's probably easier to go with the in-memory stack for testing rather than try to completely stub core data.

In order to satisfy that, I would expect only a single interface (protocol) and a way to inject that into my System Under Test. The asynchronous construction pattern we're using here complicates the problem a little, though...

from coredatastack.

Based on discussion with @rcedwards we're going to close this for now, in favor of making the SQLite and in-memory store configurations more compatible with each other. (See #27)

from coredatastack.