Comments 5
Вы используете ваш Mapper в отрыве от HTTP Client? Ведь обычно каждый сетевой запрос имеет фиксированный контракт. Добавить ассоциированный тип и сразу в него парсить. И вот уже из двойной прослойки можно выбрасывать
SignalProducer<Data, Error> и сразу получать SignalProducer<MappingResult, Error> на выходе. А потом еще поверх вашего swagger файла написать парсер, который сразу будет генерировать enum с описанием сетевых запросов и ответов.
У меня была похожая реализация слоя модели, и я как-то захотел заменить Realm на CoreData. Это оказалось нетривиально, и я в конце концов к этой идее потерял интерес и отказался от нее.
С описанной реализацией Translatable заменить Realm на CoreData без серьезных изменений не получится, т.к. NSManagedObject нужно создавать в контексте (NSManagedObjectContext), а в интерфейсе Translatable это никак не учитывается.
В отличие от Realm, в CoreData нет понятия первичного ключа как такового — это не база данных, а object graph and persistence framework (конечно, ключи там есть на уровне нижележащей БД, но абстрагированы от конечного пользователя). Т.е. это будет еще одной сложностью.
Поскольку Storage закрыта протоколом, мы не зависим от реализации конкретной базы данных и при необходимости можем заменить Realm на CoreData.
С описанной реализацией Translatable заменить Realm на CoreData без серьезных изменений не получится, т.к. NSManagedObject нужно создавать в контексте (NSManagedObjectContext), а в интерфейсе Translatable это никак не учитывается.
func object<T: Translatable>(byPrimaryKey key: AnyHashable) -> T?
В отличие от Realm, в CoreData нет понятия первичного ключа как такового — это не база данных, а object graph and persistence framework (конечно, ключи там есть на уровне нижележащей БД, но абстрагированы от конечного пользователя). Т.е. это будет еще одной сложностью.
ViewModel подготавливает все данные для view
Также ViewModel управляет логикой навигации
а это «формально не противоречит принципу S», по-вашему?
Бывают случаи, когда один и тот же метод нужен в разных роутерах
т.е. архитектура завязана на конкретный язык? в obj-c к протоколу не создать extension.
По факту, Assembly решает эту проблему…
Не скажу, что я люблю VIPER, но вот не понял из статьи: чем же он так плох с его «обслуживающим кодом»? Ведь, по сути, тут описан просто урезанный VIPER с нарушениями принципа ед. ответственности, которые вообще возможно сделать только за счёт плюшек конкретного языка (к которому не должна быть привязана архитектура)…
Ведь, по сути, тут описан просто урезанный VIPER с нарушениями принципа ед. ответственности, которые вообще возможно сделать только за счёт плюшек конкретного языка (к которому не должна быть привязана архитектура)…
Все верно. И при разрастании и усложнении проекта придется всё-равно идти в сторону VIPER.
Sign up to leave a comment.
Архитектурные подходы в iOS-приложениях