Как стать автором
Обновить

Комментарии 2

Модель ячейки контейнера знает о своей ячейке и какой в нее помещают контент.

Но ведь слоистая архитектура... Модель вложена в контент, вложенный в ячейку. А значит модель, не имеет права знать ни о контент-вьюхе, ни о ячейке.

То же самое относится к размерам, инсетам и (О! Боже!) обработчикам действий пользователей. Даже количество линий в метке и то моделью задается. Вы опустили на уровень ниже ответственности более высокого уровня. `UIEdgeInsets` не зря в ObjC имел префикс UI. Сразу было понятно, что не стоит эту штуку опускать ниже. То же самое касается даже числа линий в метке при отображении текста. Вьюха. Вьюха эти параметры определяет. Возьмите другую вьюху с другими настройками и подставьте ее вместо текущей, и вам не придется менять модель. Совсем. И не придется писать код, проксирующий настройки из модели во вьюху. Совсем. Это ведь бесполезный код. Лишний, вредный.

Именно поэтому вся ваша история и несовместима с InterfaceBuilder.

Если поднимите назад на уровень выше все вещи слоя представления, то ваша схема прекрасно будет работать даже с ячейками, сверстанными в IB. По крайней мере у нас работает.

Для настройки вьюх поглядите паттерн декоратор. Все, что вы опустили в модельку, разместиться в декораторе, располагающемся на уровне представления.

Бонусом вы потеряете жесткую связь 1 к 1 от вьюхи к ее модели и сможете оперировать протоколами, вешая один и тот же протокол, необходимый вьюхе, на разные модельки, что даст вам большую гибкость при работе с данными и отменит жесткий меппинг из одних структур в другие.

Ну и мелочь: `ConteinerItem` -> `ContainerItem` все же.

Но ведь слоистая архитектура... Модель вложена в контент, вложенный в ячейку. А значит модель, не имеет права знать ни о контент-вьюхе, ни о ячейке.

А где здесь нарушение слоистой архитектуры? Обе сущности находятся в одном слое UI, модель тупая и нужна для инкапсуляции конфигурируемых полей вью и выступает ее простым контрактом. В слое бизнес-логики другие модели DTO, которые уже не знают про вью.

То же самое относится к размерам, инсетам и (О! Боже!) обработчикам действий пользователей. Даже количество линий в метке и то моделью задается. Вы опустили на уровень ниже ответственности более высокого уровня. `UIEdgeInsets` не зря в ObjC имел префикс UI. Сразу было понятно, что не стоит эту штуку опускать ниже. То же самое касается даже числа линий в метке при отображении текста. Вьюха. Вьюха эти параметры определяет. Возьмите другую вьюху с другими настройками и подставьте ее вместо текущей, и вам не придется менять модель. Совсем. И не придется писать код, проксирующий настройки из модели во вьюху. Совсем. Это ведь бесполезный код. Лишний, вредный.

Почему вью не может быть конфигурируемой количеством строк и другими параметрами? Плодить отдельные вью под каждый кейс использования - это уже овер-инжиниринг.

`UIEdgeInsets` не зря в ObjC имел префикс UI. Сразу было понятно, что не стоит эту штуку опускать ниже.

По этой логике даже картинку в UIImageView нельзя положить, она принимает UIImage, у него тоже есть префикс UI.

Именно поэтому вся ваша история и несовместима с InterfaceBuilder. 

Если поднимите назад на уровень выше все вещи слоя представления, то ваша схема прекрасно будет работать даже с ячейками, сверстанными в IB. По крайней мере у нас работает.

На самом деле ничего не мешает верстать саму вью в IB, просто это будет уже менее удобно.

Для настройки вьюх поглядите паттерн декоратор. Все, что вы опустили в модельку, разместиться в декораторе, располагающемся на уровне представления.

Не совсем понимаю, что будет декорироваться в этом случае?

  • Если декорировать экземпляр вью, то это оверхэд, так как нам не нужно создавать вью при каждом обновлении, нам нужно задать ее параметры и скормить их data source коллекции, который уже посчитает дифф и создаст ячейку, только если это нужно.

  • Если декорировать тип вью, то чем это отличается от подхода из статьи?

Бонусом вы потеряете жесткую связь 1 к 1 от вьюхи к ее модели и сможете оперировать протоколами, вешая один и тот же протокол, необходимый вьюхе, на разные модельки, что даст вам большую гибкость при работе с данными и отменит жесткий меппинг из одних структур в другие.

О каком маппинге речь?

Мы умышленно пришли к связи 1 к 1, так как это уменьшает количество кода на стороне использования и дает строгую типизацию с автодополнением в Xcode.

Ну и мелочь: `ConteinerItem` -> `ContainerItem` все же.

Спасибо, опечатка в статье, поправим.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий