Разделение модели домена Rails от ActiveRecord

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

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

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


person Community    schedule 25.07.2011    source источник


Ответы (2)


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

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

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

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

person eulerfx    schedule 26.07.2011
comment
Спасибо, это указывало мне на направление потока stackoverflow stackoverflow.com/questions/2521522/, а затем, в свою очередь, Джей Филдс, который поработал над шаблонами докладчиков, представленными на RailsConfEU 07 blog.jayfields.com/2007/09/ - person ; 26.07.2011
comment
... Я думаю, это подбрасывание между шаблоном ведущего или перемещением связанных творений и другой логикой к модели, которую Джеймис Бакс вращает на толстой модели тонкого контроллера, которая кажется нормой в мире рельсов. На самом деле я предпочитаю шаблон презентатора, я думаю, он может производить более чистый код. Я также обнаружил, что есть книга Advanced Rails Recipes, которая содержит реализацию Jay Fields паттернов презентатора. Я посмотрю, смогу ли я найти и позаимствовать копию из библиотеки. Я надеюсь, что кто-то расширил генераторы Rails на основе этой работы. - person ; 26.07.2011

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

person qertoip    schedule 26.02.2012