Комментарии 4
Хорошая статья, но больше половины это пересказ книги. Но спасибо вам за текст, я уже думал эту книгу никто не читал, все только ругают
На диаграмме направления зависимостей в центре логика приложения, это точно? 🤓
У Мартина вообще 3 уровня, и четвертого, как-будто, и не нужно никогда (если вспомнить о назначении каждого слоя). Как-будто логика приложения – это и есть то, как бизнес-модель проецируется в представление и обратно. Как-будто логика приложения – это содержимое уровня контроллеров.
Вообще, конечно, узнать бы у автора, что подразумевается под логикой приложения. @Ognev_Anton Определения в статье нет, термин используется только на картинке. Но можно предположить, что под этим уровнем имеется ввиду вот это из статьи: "Настройка окружения, заголовки, работа с запросами и сессией, кодирование и декодирование пишутся один раз и являются общими для всего приложения."
В таком случае, это действительно уровень адаптера и преобразования данных – только с другой стороны кольца – не со стороны представления, а со стороны сервера. По Мартину входов в эти кольца может быть сколько угодно.
Но так исторически сложилось, что в иос (да и андроиде, и вообще в мобилах) – общение с сервером воспринимается, как самая главная часть бизнес логики, на которую и идет все равнение (т.е.от нее зависит все). Сервер для мобильной разработки – главный закон, решения сервера не оспариваются, а выполняются... У нас в приложении так же. Поэтому это более глубокий уровень, что, похоже, и отображено на диаграмме.
Но вот вопрос: какой из подходов лучше и почему (традиционный используется уже лет 15)? Стоит ли нам инвертировать зависимости между бизнес-логикой и адаптером к серверу (то, что в статье названо логикой приложения)? От чего это зависит? Как это замерить?
Что думаете? Сможете нам помочь в ответах на эти важные для нас вопросы?
Спасибо за подмеченный нюанс!
К какому компоненту отнести тот или иной класс? Мой опыт разделения функциональности между компонентами