Разделяне на Rails Domain модел на Activerecord

Четох книгата "SQL Antipatterns: Избягване на клопките на програмирането на бази данни", особено около анти шаблона на магическите зърна. В него се показва диаграма, отделяща активни записи чрез използване на модел на домейн и има пример в PHP, но не и Rails, той се отнася до това като HAS-A агрегиране между модели на домейн и изгледи/контролери и HAS-A композиция между модели на домейн и активни записи (I приемете, че това е UML език).

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

Тоест, за създаване на модел без таблица или друг клас, който да се използва като модел на домейн, действащ като слой между контролери и обекти на активен запис (които от своя страна са картографирани към таблици), така че контролерите да имат по-добра изолация и да не е необходимо да знаят нищо за основната база данни и нейната структура. Той също така дава възможност да се отдалечите от методите 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
... Мисля, че това е хвърляне между шаблон на презентатор или преместване на асоциирани творения и друга логика на модела Jamis Bucks се върти върху модела на тънък контролер, който изглежда е норма в света на релсите. Всъщност предпочитам модела на презентатора, мисля, че може да създаде по-чист код. Също така открих, че има книга Advanced Rails Recipes, която съдържа реализация на Jay Fields на презентиращи модели. Ще видя дали мога да намеря и да взема копие от библиотека. Надявам се, че някой е разширил Rails генераторите въз основа на тази работа. - person ; 26.07.2011

Може да намерите за полезно това базирано на Rails приложение: https://github.com/qertoip/guru_watch - то има за цел да покаже как да отделяте от ActiveRecord по начин, препоръчан от Robert C. Martin. Известен е като Архитектура, управлявана от използване на сценарий или модел Entity-Control-Boundary.

person qertoip    schedule 26.02.2012