Rails Доменная модель развязки Activerecord

Question

Я читал книгу «Антипаттерны SQL: предотвращение ловушек при программировании баз данных», особенно об анти-паттерне «волшебные бобы».На нем показана диаграмма разъединения активных записей с использованием модели домена и приведен пример на PHP, но не на Rails, это называется агрегацией HAS-A между моделями домена и представлениями / контроллерами и композицией HAS-A между моделями домена и activerecords (Iпредположим, что это UML говорить).

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

То есть для создания модели без таблиц или другого класса, который будет использоваться в качестве модели домена, выступающей в качестве слоя между контроллерами и объектами activerecord (которые, в свою очередь, отображаются в таблицы), чтобы контроллеры имели лучшую изоляцию и нене нужно ничего знать о базовой базе данных и ее структуре.Это также дает возможность отказаться от методов CRUD, которые не объясняют прикладных требований, к которым они применяются, еще одна критика в книге.

Answer 1

Может оказаться полезным это приложение на основе Rails: https://github.com/qertoip/guru_watch - оно призвано показать, как отделить ActiveRecord способом, рекомендованным Робертом К. Мартином. Он известен как архитектура, управляемая прецедентами, или шаблон Entity-Control-Boundary.

Answer 2

Мои комментарии приходят от использования DDD вместе с ASP.NET MVC.Рекомендуемый подход к привязке контроллеров к объектам домена заключается в использовании моделей представлений, которые DTO предназначены специально для привязки к определенному представлению.Модель представления обеспечивает очень необходимый буфер между механизмами связывания и моделью предметной области.Часто данное представление может представлять собой композицию из нескольких объектов домена или даже объектов отчетности и, следовательно, не напрямую связано с каким-либо данным объектом домена.Наличие атрибутов, необходимых для представления, объявленного в модели представления, делает эти требования к данным явными и не приводит к попыткам настроить модель предметной области для удовлетворения потребностей представления.

Недостатком, конечно же, является потенциальное появление иерархии двойного класса, где у вас может быть модель представления, которая соответствует многим объектам вашего домена.Однако на практике я обнаружил, что поддерживать иерархию двойных классов гораздо проще, чем беспокоиться о последствиях изменения сущности домена.Взгляните на The Relase of ReUse .

В системе SOA объекты, которые просматривают «обтекание» моделей, могут быть не объектами домена, а DTO, представляющими эти объекты домена.Это не нарушает структуру моделей представлений, поскольку они сами являются DTO и не имеют поведенческих аспектов, только данные.Взгляните на эту статью, в которой обсуждается природа данных на границах приложения.

Чтобы ответить на ваш вопрос, я считаю, что создание моделей уровня представления было бы полезным для приложения Rails,учитывая все предостережения выше.Модели представлений будут заполняться данными либо из объекта активной записи, либо из любого другого объекта, содержащего данные, которые должны быть представлены, и затем, когда пользователь вводит данные, модель представления будет обновлять объект активной записи или объект модели домена.Хотя я бы не стал называть этот слой модели представления моделью домена.