Приложения на Rails, которые отделяют ActiveRecord от Business Logic

Недавно я наткнулся на доклад Роберта Мартина (дядюшки Боба) о том, как структурировать приложение rails на основе вариантов использования. Мне это показалось очень интересным.

Вот ссылка на основной доклад: Архитектура: потерянные годы

Вот пример проекта, который структурирует приложение на основе принципов, упомянутых Робертом Мартином в его выступлении: Guru Watch

Мне было интересно, существуют ли хорошо зарекомендовавшие себя приложения rails, которые структурированы таким образом (подход, основанный на сценариях использования / архитектура Entity-Control-Boundary / разделение серверной части от внешнего интерфейса)


ruby-on-rails decoupling activerecord rails-activerecord
person Karan    schedule 07.01.2013    source источник
comment
вас может заинтересовать blog.firsthand.ca/2011 /10/rails-is-not-your-application.html   -  person apneadiving    schedule 07.01.2013
comment
это может вас заинтересовать stackoverflow.com/questions/ 8743937 /   -  person Helio Santos    schedule 07.01.2013
comment
Я не могу предложить ответа, но я обнаружил, что скринкасты «Уничтожить все программное обеспечение» содержат интересные советы с точки зрения общего разделения вашего приложения, использования классов обслуживания, сохранения ваших моделей ActiveRecord в виде действительно тонкого слоя, содержащего только данные, и т. Д. к сожалению, не бесплатны, и многие из них посвящены действительно второстепенным темам, но они могут стать хорошей отправной точкой. Вот каталог: destroyallsoftware.com/screencasts/catalog   -  person Nerdmaster    schedule 16.01.2014

Ответы (1)


arrow_upward
2
arrow_downward

Я не могу поделиться кодом, но могу указать вам направление. Мы использовали этот драгоценный камень в нашем приложении: https://github.com/collectiveidea/interactor.

Я был очень вдохновлен докладом Мартина, и разработка этого приложения прошла очень хорошо :). В случае разделения ActiveRecord и Business Logic мы сделали следующее:

Каждый класс в нашей бизнес-логике имел своего рода аналог DatabaseEntity. Этот аналог использовал другой класс - наш адаптер к ActiveRecord. Он запрашивал соответствующую модель ActiveRecord и преобразовывал экземпляры ActiveRecord в экземпляры наших классов бизнес-логики.

Ведь большая часть кода была сосредоточена в этом адаптере.

person marvelousNinja    schedule 23.01.2014
comment
Можете ли вы сказать, насколько сложно было реализовать это решение? И для вас это стоило дополнительных накладных расходов на работу в этих классах по сравнению с дизайном, а также для облегчения понимания и рефакторинга основной логики приложения? - person cllamach; 08.06.2016