Initializers refactored

[ovrchk]

Сделал первоначальный инициализатор вспомогательным, и добавил один вспомогательный инициализатор с NSPersistentContainer и один назначенный с NSPersistentStoreCoordinator

Сделал это затем, что мне показалось нелогичным что на каждый экземляр DAO стек CD настраивается по-новой, ведь можно в каждый DAO инжектить один и тот же NSPersistentStoreCoordinator извне

Плюс, по своей структуре изначальный инициализатор выглядел как вспомогательный, а новый назначенный инициализатор выполняет одну конкретную задачу - инициализурует экземпляр транслятором и координатором

[sevlaan]

Мне кажется идеологический смысл DAO как раз в том, чтобы полностью абстрагировать базу данных в приложении. То есть сделать единую точку входа для всех манипуляций, связанных с кэшированием, без погружения в детали реализации. Как мне видится, ты сделал шаг в сторону последнего - вынес конфигурацию стека конкретной ORM(CoreData) за пределы DAO. Интересно что думают по этому поводу ребята.

[ovrchk]

Согласен, но ведь абстракция заключается в том, что конкретная реализация DAO закрывается протоколом и, допустим, сервисный слой не будет иметь представления как именно хранятся данные, идеологически тут все в порядке

А в детали реализации разработчик все равно точно будет вдаваться - в момент инициализации конкретного экземпляра DAO

[vani2]

Расширять инициализатор в таком стиле – можно. Назначение DAO – синхронный CRUD-интерфейс. Не ок, если при этом разработчику приходится думать о потокобезопасности и знать "слишком много" про CoreData при вызове CRUD-методов. В том числе, например, если нужен FetchResultController, DAO не надо использовать/расширять.