Мы используем направляющие ActiveRecord в качестве Гибридной Структуры, т.е. Данные Structure+Object?
Я использовал направляющие больше 4 лет так, очевидно, мне нравятся направляющие и как выполнение вещей направляющие Путь, и иногда я невольно падаю на темную сторону.
Я недавно забрал Чистый Код Дяди Bob. Я нахожусь на Главе 6 и немного смущен, нарушаем ли мы как разработчики направляющих очень фундаментальное правило дизайна OO, т.е. Закон Demeter или инкапсуляции? В Законе Demeter говорится, что объект не должен знать внутренности другого объекта, и он не должен вызывать методы на объекты, которые возвращаются методом, потому что, когда Вы делаете это затем, он предполагает, что один объект знает слишком много о другом объекте.
Но очень часто мы называем методы на другом объекте из модели. Например, когда у нас есть отношения как 'Порядок, принадлежит пользователю'. Затем очень часто мы заканчиваем тем, что делали order.user.name или препятствовали тому, чтобы он был похож на железнодорожную аварию, мы настраиваем делегата, чтобы сделать order.name.
Не то, что все еще как нарушение закона Demeter или инкапсуляция?
Другой вопрос: ActiveRecord является просто Объектом Структуры данных или Передачи данных, который взаимодействует через интерфейс с базой данных?
Если да, то разве мы не создаем Гибридную Структуру, т.е. половину объекта и половины структуры данных путем помещения наших бизнес-правил в Модели ActiveRecord?
4 ответа
Рельсы - это рельсы. Что еще можно сказать. Да, некоторые идиомы в Rails нарушают принципы хорошего дизайна. Но мы терпим это, потому что это путь Рейлса.
Сказав это, мы слишком много используем модели в большинстве рельсовых приложений. Слишком часто я вижу код просмотра моделей, получающий прямой доступ к ним. Я вижу бизнес-правила, сложенные в активный объект записи. Лучшим подходом было бы изолировать бизнес-правила от активных записей и изолировать представления от моделей. Это не нарушило бы никаких идиом рельсовых правил и сделало бы рельсовые приложения намного более гибкими и удобными в обслуживании.
IMHO если вы слишком сильно придерживаетесь пуристического подхода, то вы попадаете в такой бардак как Java, где используются все правильные шаблоны дизайна, но никто не может вспомнить восемь строк кода, которые нужно просто открыть файл и прочитать его содержимое.
Фреймворк ActiveRecord от Rails - это реализация шаблона дизайна Active Record Мартина Фаулера Active Record . Active Records в Rails - это, конечно, не просто тупые структуры данных или DTO, потому что у них есть поведение: они выполняют валидацию, они могут сказать вам, изменились ли их атрибуты и т.д. и вы свободны и действительно поощряете , добавлять туда свою собственную бизнес-логику.
Rails в целом поощряет хорошую практику, например, MVC и синтаксический уксус, чтобы сделать плохие вещи сложными и/или уродливыми.
.Что касается "закона Деметра", то я не упомянул понятие расстояния. Под этим я имею в виду: "Насколько тесно связан объект?". По моему мнению, это имело бы некоторое значение, хочу ли я следовать "Закону Деметры" или нет.
В случае ActiveRecord объекты, вовлеченные в большинство нарушений LoD, неразрывно связаны в тесную связь. Изменение внутренней структуры данных этих объектов требует внесения изменений в базу данных для отражения этой новой структуры. Таблицы базы данных, как правило, "привязаны" в единую базу данных, что даже отражает эти "ассоциации" через ограничения по посторонним ключам (или, по крайней мере, содержат первичные и посторонние ключи)
Таким образом, я обычно не занимаюсь отслеживанием LoD между моими объектами АР. Я знаю, что они тесно связаны друг с другом в силу самой своей природы.
С другой стороны, меня больше волнует LoD между более удаленными объектами, особенно теми, которые пересекают границы MVC или любого другого подобного конструктивного устройства.
.Да, ActiveRecord намеренно нарушает инкапсуляцию. Это не столько ограничение Rails, сколько ограничение шаблона, на котором он основан. Мартин Фаулер, чье определение ActiveRecord в значительной степени было шаблоном, используемым Rails, говорит об этом в главе об ActiveRecord POEAA :
Еще один аргумент против Active Запись заключается в том, что он соединяет объект дизайна в базу данных дизайн. Это усложняет реорганизовать дизайн как проект идет вперед.
Это общая критика Rails со стороны других фреймворков. Сам Фаулер говорит, что ActiveRecord в основном используется
... для логики предметной области, которая не слишком сложный ... если ваша бизнес-логика сложный, вы скоро захотите использовать свой прямые отношения объекта, коллекции, наследование и пр. Их нелегко сопоставить с Active Record.
Фаулер продолжает, что для более серьезных приложений со сложной логикой предметной области предпочтительнее использовать шаблон Data Mapper , который лучше справляется с разделением слоев. Это одна из причин того, что предстоящий переход Rails на Merb в целом рассматривается как положительный шаг для Rails, поскольку Merb использует шаблон DataMapper в дополнение к ActiveRecord.
Я не уверен, что Деметра является основной проблемой ActiveRecord. Скорее, я думаю, что нарушение инкапсуляции между уровнями данных и домена нарушает принцип единой ответственности дяди Боба . Я думаю, что Деметра является более конкретным примером того, как следовать принципу открытости / закрытости. Но я думаю, что общая идея, лежащая в основе всего этого, одна и та же: классы должны делать одно и быть устойчивыми к будущим изменениям, что в некоторой степени не является ActiveRecord.