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

Question

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

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

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

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

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

Спасибо.

Answer 1

Насколько я понимаю, видео по Дяди Боба, используя «EBI» (Entity, Boundary, и Interactor) вы должны полностью отделить свой бизнес поведение/состояние из рамок/OS и услуг.

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

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

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

Где этот отпуск AR? Ну, 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" 

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

1. Хорошая архитектура позволяет отложить серьезные изменения
2. Хорошая архитектура не допускает крупных изменений

Последнее примечание: по сравнению с шаблоном 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.

Answer 2

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

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

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

• Dependency Injection
• Докладчики
• Стратегия шаблон
• DCI

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

Вот настоящая жемчужина, которая проясняет суть проблемы:

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

Corey Haines ставит это по-другому:

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

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

Answer 3

Это также должно представлять интерес.Это другая книга, не названная по имени в "Architecture: The Lost Years"

«Разработка гибких программных продуктов: принципы, шаблоны и практика», «Дядя Боб» Мартин.

Взятый с этого SE question & answer. Прочитайте также other answers.