Практический пример архитектуры с использованием EBC?

Меня заинтриговал Роберт Мартин, говорящий о "Архитектура: Потерянные годы" . В нем он обсуждает шаблон структуры Entity, Boundary, Control, на котором основан MVC. Мне нравится идея отложить архитектурные решения. Он описал отсрочку решения о том, как реализовать уровень БД в своем собственном приложении Wiki FitNesse. Я органично отложил решения, подобные этому, в моем собственном кодировании, хотя не было предвзятого модульного дизайна, который вызвал это.

Я хочу лучше понять эту архитектуру EBC (которая, по-видимому, тесно связана с DCI) с практической точки зрения, чтобы я мог начать использовать ее в небольшом проекте. Я хочу извлечь выгоду из "отложенных решений" и возможности поменять аспекты дизайна, такие как пользовательский интерфейс.

Rails, например, использует форму EBC (MVC), но она так сильно испекла, что не может легко заменить альтернативный интерфейс, таким образом преобразовывая приложение Rails в консольное приложение или настольное приложение. Интригующая вещь о дизайне для меня - это способность преобразовывать приложения, заменяя одну вещь и подключая другую. То есть, я задаюсь вопросом о создании архитектуры так, чтобы можно было, как бы говоря, заменить пользовательский интерфейс или слой персистентности. Я чувствую, что если архитектура хорошо спроектирована, связь будет низкой, и такой подвиг будет в пределах досягаемости.

Я заказал книгу Ивар Джекобсон, о которой упомянул Боб в его разговоре. Я искал онлайн совсем немного, но все примеры, которые я нашел, показывают простые диаграммы. Я говорю код. Я бы выиграл от изучения нескольких простых классов, демонстрирующих концепцию, и продемонстрировал, как можно заменить один слой (UI, DB) для какой-либо другой реализации, используя граничные классы.

Если кто-то не может указать мне на хороший ресурс, иллюстрирующий это, трудно ли это взломать? Может быть, мы могли бы использовать резервный пример, используемый во многих книгах по программному обеспечению: магазин для проката видео (почти реликвия в наши дни). Просьба продемонстрировать, как можно изменить локальный интерфейс или уровень БД. Одна вещь, которая меня смущает, - это взгляды. Я не могу сказать по диаграммам, которые я видел, если представления являются самими граничными классами или если они просто общаются с ними. Кроме того, Боб упомянул, что первоначальное намерение EBC состояло в том, что у нас было бы много микро-представлений, а не только одного макро-представления (как мы это делаем в типичном MVC); Мне любопытно, как это может выглядеть. (Я предпочитаю Ruby или JavaScript, но, поскольку нищие не могут быть выборами, любой пример будет в порядке.)

Спасибо.

Ответ 1

Насколько я понимаю видео дядюшки Боба с помощью "EBI" (Entity, Границы и Interactor), вы должны полностью отделить ваше поведение/состояние бизнеса из фреймворков/ОС и служб.

Таким образом, в случае приложения Rails ваше поведение/состояние вашего бизнеса полностью не зависит от среды Rails и, следовательно, может быть протестировано как с rspec без запуска Rails!

Таким образом, на стороне бизнеса у вас есть классы Границы, которые взаимодействуют с Rails-сайтом, используя модели запросов и ответов (очень простые держатели данных, чтобы их не обменивали с обычными моделями из Rails). Только классы Границы взаимодействуют с классами Interactor, которые реализуют (деловые) варианты использования/сценарии. И только классы Interactor взаимодействуют с классами Entity, которые инкапсулируют бизнес-состояние.

На стороне Rails вы найдете классы Контроллер, взаимодействующие с классами Границы (с использованием моделей запроса) и назад класс Граница взаимодействует с Presenter (с использованием модели Response). Только Ведущие/Контроллеры взаимодействуют с представлениями (с помощью моделей (снова простые держатели данных). Обратите внимание, что в области Rails Ведущие наиболее вероятны Контроллеры.

Где это оставляет AR? Well AR просто обеспечивает постоянное обслуживание. На уровне уровня Presenter/Controller вы найдете классы Сервис, которые предоставляют свои услуги классам Границы. Таким образом, они предоставляют все необходимые сервисы, которые являются основами/ОС/технологией, зависящими от устойчивости, безопасности, синхронизации, уведомления и т.д.

С помощью этой архитектуры вы действительно сможете повторно использовать свою бизнес-логику и полностью заменить технологию пользовательского интерфейса или базы данных. Например, перенос на мобильный (iOS, Android, Windows) должен быть довольно простым.

С Rails ваша папка приложения может выглядеть так:

app/
    controllers/    Only these interact with Boundary classes
    models/         simple data-holders, no AR here! (see services)
    views/  
    services/       AR-stuff
    boundaries/     To be tested without Rails
         models/    Request & Response
    interactors/    use cases / scenarios, to be tested without Rails
         entities/  "the real business model without technical dependencies"

С этой архитектурой вам нужно немного закодировать код, но не забывайте о преимуществах хорошей архитектуры:

Хорошая архитектура позволяет отложить серьезные изменения.
Хорошая архитектура максимизирует (крупные) изменения, не внесенные

Последнее примечание: по сравнению с шаблоном MVC его больше похоже на M заменяется на EBI, C может быть разделен на CP/resenter), и добавляется S (ervice). Так что это можно было бы назвать: VCPS/EBI, но это звучит уродливо для меня;-) BEPVICS может быть?

@Seralize, спасибо за ваши отзывы.

Позвольте мне попытаться ответить на ваши вопросы, пока я их понимаю: материал в сервисах связан с Rails. Они обеспечивают реализацию логики на стороне EBI. В условиях безопасности вы должны четко понимать, какие (количественные) требования вы имеете, поэтому вы знаете, какую логику вы можете реализовать на стороне EBI, например (бизнес-правила) о том, когда пользователь (роль) имеет доступ к какому контенту (например, и должны быть аутентифицированы).

Это означает, что реализация аутентификации будет реализована с использованием Rails, эта служба будет использоваться EBI. Эта логика, связанная с безопасностью в EBI, довольно легко повторить в примере Java GUI. Там вам нужно только переопределить службу проверки подлинности.

Чтобы быть понятным в примере безопасности:

У стороны EBI есть логика: что нужно, какая защита и когда и как. Rails ничего не знает об этом, он запрашивает, что делать со стороны EBI, и сторона EBI запрашивает сторону Rails для работы.

Сторона Rails только реализует способ обеспечения безопасности, например, просить пользователя пройти аутентификацию (когда это необходимо) и передать результат этого в EBI, чтобы логика могла решить, что делать дальше.

EBI требует, чтобы обе стороны были развязаны и независимы. Это было так, как вы разрабатывают EBI как библиотеку с определенным API.

Ответ 2

Спросите, и вы получите. Я не открывал глаза и открыл этот ресурс Авди Гримм:

http://avdi.org/devblog/2011/11/15/early-access-beta-of-objects-on-rails-now-available-2/

В нем он затрагивает некоторые причины, по которым проекты Rails настолько тесно связаны как с каркасом, так и с ActiveRecord. Он использует TDD для обеспечения свободной связи с методами, такими как

Инъекция зависимостей
Ведущие
Шаблон стратегии
DCI

Это дает хорошее начало для ответа на этот вопрос практическим способом. (Это стоит 5 долларов за раннюю бета-версию, но в конечном итоге будет бесплатной.) Фактически, это первый ресурс, который я нашел, который делает. Пожалуйста, добавьте любые другие, которые вы найдете.

Здесь настоящий камень, который освещает суть проблемы:

Однажды, после нескольких лет наблюдения и рассмотрения технического долга, возникшего в различных кодовых базах Raining в результате активной связи, основанной на ActiveRecord, у меня было прозрение. Что делать, если мы перестали рассматривать ActiveRecord как основу наших классов моделей, а вместо этого запрограммировали так, как если бы ActiveRecord был просто частной деталью реализации?

Кори Хейнс ставит его по-другому:

Я вытаскиваю поведение из своих моделей в другие объекты, которые обертывают модели. Я предпочитаю делать AR-объекты простыми обертками вокруг объектов db-доступа в AR.

У меня довольно строгое правило, что действия контроллера не могут использовать AR-искатели или, фактически, взаимодействуют с AR вообще. AR должен быть доступен в api-методах внутри вашей модели, а не снаружи.

Ответ 3

Это тоже будет интересно. Это другая книга, не названная по имени в "Архитектура: Потерянные годы"

"Agile Software Development: принципы, шаблоны и практика", "Дядя Боб" Мартин.

Взято из этого вопроса SE. Прочтите другие ответы.