Итак, по поводу интерактора. В принципе я согласен с тем, что он должен просто возвращать свою бизнесовую модельку в презентер, а презентер пускай сам там мапит.
Но. Еще одна модель и маппинг. Практически всегда вы не переиспользуете интерактор таким образом, чтобы подцепить его к абсолютно другой вьюшке. Максимум - вы просто делаете другую имплементацию. Да, есть интеракторы, которые могут понадобиться в нескольких местах приложения. Но обычно они просто заиспользуются другими интеракторами, которые уже работают с вьюшкой.
Проанализировав все это, я понял, что еще одни модели в принципе не нужны.
Кроме того, если мы делаем еще один модельки, то маппинг достается презентеру. А мне его стало жалко. Ну как-то преобразование моделей к UI слою не очень то по мне (а в UI слое у меня View and Presenter), но это мое субъективное ощущение. Я решил вопрос маппинга максимально делегировать интерактору. Понятное дело, Интерактор это делегирует специальному классу.
Поэтому да, я тут чуть уклонился от канонов. Но это я сделал для большего удобства и уменьшения оверхеда.
Вообще тут боль большая с этими модельками и маппингом их. Иногда это раздражает)
@xanderblinov @senneco вы вроде говорили, что у вас как-то автоматом это делается? Вообщем у кого какие идеи, как минимизировать эту боль?
@mansonheart Киньте, пожалуйста, ссылки, где сказано, что domain ничего не должен знать о других слоях. Помечу у себя.
Повспоминал немного инфы на этот счет. Начну с рассказа почему считаю, что репозитории и их интерфейсы не должны храниться вместе в слое данных. Некоторое время назад, у меня была задача на новом проекте использовать Realm вместо привычного Sqlite. При этом была вероятность, что где в середине проекта мне захочется вернуться назад к Sqlite. Архитектура, которая позволяла менять дата слой, незатрагивая других выглядела выгодно. Кoнечно, нужно было бы перпеписать большой объем кода, сопастовимый с объемом кода, если интерфейсы репозиториеев хранить в дате слое. Но в случае, если хранить интерфейсы репозиторий в дате, то получается, что бизнес логика знает о деталях реализции моей БД. Возможно даже это означает, что мне придется как то в эти детали вникать, например, мы иногда в моделе дата слоя можем сохранить сложную структуру прям json'ом и парсить при необходимости в объекты. Поместив интерфейс репозитория в слой с бизнес-логикой я смогу гарантировать, что мне никогда не придется вникать в подобные вещи, так как в слой с бизнес-логикой мне зайдут уже модели бизнес-логики. Стоит отметить, что это был мой первый проект с такой архитектурой и я некоторых вещей не понимал еще и на всякий случай, чтобы не сбится с пути и чтобы точно с Realm ничего не заскочило в логику, сделал по примеру Фернандо слой с бизнес-логикой java модулем (кстати так поступаю до сих пор). Таким образом, действительно поменять Realm на что то другое стало проще. Правда, я сразу лишился некоторых фичей реалма, заперев его в слое данных. Дядюшка Боб, кстати, говорит о том, что интерфейсы и их реализации не должны лежать в одном пакете, несмотря на то что у них сильная физическая связь. Он считает правильным, когда интерфейс принадлежит клиенту, который его использует [1]. Так же он об этом писал в своей статье по архитектруре, там же про то, что логика не должна зависисеть от дата слоя. "Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database." [2] Собстенно он же пишет, что ничто не должно влиять на слой с бизнес правилами: "We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. This layer is isolated from such concerns." [2]
В целом получается, что такую схему зависимостей я выбрал потому, что в теории она позволяла мне с минимальными усилями мигрировать на другую БД и она была описана в статьях и книжках, что сводило к минимуму вероятность ошибок с моей стороны.
Фаулер, кстати, такую архитектуру называет Hexagonal architecture [3]. Он считает, что в разделенной на слои архитектуре, зависимости должны быть направлены сверху вниз, представление зависит от бизнес-логики, бизнес-логика от дата слоя. Но также говорит о том, что возможен такой вариант, когда бизнес-логика не зависит ни от одного слоя. При этом дополнительно выделяет слой "Data Mapper" [4]. Точнее не он сам выделяет, просто рассказывает об этом.
Есть еще одна замечательная книга от Марка Симана (работал в Microsoft), посвященная DI в .NET. Из .NET там только конкретные примеры и описания IoC-контейнеров, в остальном там много хорошего теоретического материала, по DI лучше литературы вы не найдете, кстати, так что очень советую. Так вот, он там рассматривает простенькое приложение на
ASP.NET MVC. Подробно рассматривает каждый из трех слоев, рассказывает, что в каком слое у него есть. Сначала он рассматривает неверную, на его взгяд реализацию, аргументирует и рефакторит в сторону независимого слоя с бизнес-логикой.[5]
По поводу связи слоя презентации и бизнес-логики, то у меня сейчас презентеры в основном используют модели бизнес-логики. И не всегда даже маппят их в модели UI, хотя конечно такое приходится делать в некоторых случаях, но мапперы в слое презентации свои.
