Шаблон бизнес-логики на рельсах?MVCL

Question

Это широкий вопрос, и я не ценю таких коротких / тупых ответов, как: "О, это образцовая работа, этот квест задерживается (точка)"

ПРОБЛЕМА Там, где я работаю с людьми, я создал систему, которая в течение 2 лет управляла процессом производства по требованию в максимально упрощенном и широком смысле, включая продажу, покупку, сборку. Система написана на Ruby На рельсах

Приложение менялось много раз, и в результате возникает беспорядок в обратных вызовах (некоторые из них вызываются несколько раз), более 200 моделей и жирных контроллеров: Всего плохих .

ВОПРОС - есть ли гем или шаблон, предназначенный для обработки логики больших приложений Rails? Логика могла бы быть в состоянии полностью общаться с моделями (единственной заботой которых была бы обработка и проверка формата данных)

То, что я ОЖИДАЮ , заключается в том, чтобы уменьшить сложность от различных контроллеров и трудно отслеживать обратные вызовы в файлы, отвечающие за обработку логики бизнес-операций. В некоторых случаях необходимо дождаться ответа, в других достаточно проверки только входных данных, и будет происходить процесс bg.

т
-> Продать некоторые продукты (нужно дождаться окончания операции)
1. Установите вид, чтобы получить входные данные продуктов
2. Контроллер получает список продуктов, введенный сотрудником, и вызывает логику

Logic::ExecuteWithResponse('sell', 'products', :prods => @product_list_with_qtt, :when => @date, :employee => current_user()  )  

Эта логика будет обрабатывать заказ на покупку, заказ на сборку, расписание машин, резервирование склада и др.
Имейте в виду, что обратного вызова в SalesOrder недостаточно, поскольку он зависит от того, где он вызывается (для этого нет поля), зависит от класса пользователя, среди других вещей, не видимых для модели, или в некоторых случаях это будет Обработка модели займет много времени.

Answer 1

Сложность бизнес-объекта и логики должна быть решена, понята и усвоена (или, по крайней мере, хорошо документирована) для команды. Это не уйдет. У меня есть рекомендация - взять всю логику, которая присутствует в «жирных» контроллерах, и переместить их либо в объекты домена, либо в прикладные службы (сервисный уровень), либо просто в сценарии транзакций (см. «Шаблоны архитектуры корпоративных приложений» Мартина Фаулера).

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

Answer 2

Идея Service Layer состоит в том, чтобы включить логику высокого уровня, которая не связана с определенной моделью. Если вы разрабатываете корпоративную систему с несколькими интегрированными сервисами и имеете несколько источников данных, вам лучше обратиться к доменно-управляемому дизайну (DDD) Эрика Эванса. Конечно, в этом случае книга Фаулера «Образцы предприятий» также хороша.

Также посмотрите на DataMapper (2, первый был похож на ActiveRecord). Он имеет лучший подход к проектированию для систем такого типа и имеет меньше ограничений (на концептуальном уровне), чем ActiveRecord в Rails.

По правде говоря, это из-за динамичной природы людей из Ruby, которые так долго решают концептуальные проблемы ActiveRecord и пытаются удовлетворить потребности предприятия, ИМХО.

Answer 3

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

Это далеко не полномасштабный DDD, и в настоящий момент я не знаю, как DDD будет работать в Rails, однако я уверен, что это возможно, и я уверен, что кто-то сейчас работает над этим. Для моих проектов на данный момент было бы немного излишним реализовать, однако я бы рассмотрел добавление сервисного уровня.