activerecord как модель, это хорошая идея?

Question

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

Модель представляет корпоративные данные и бизнес-правила, регулирующие доступ к этим данным и их обновление. Зачастую модель служит программным приближением к реальному процессу, поэтому при определении модели применяются простые методы моделирования реального мира.

это не говорит, что модель должна представлять одну таблицу как то, что делает activerecord. И обычно в рамках транзакции, возможно, придется запросить несколько несвязанных таблиц, а затем манипулировать данными из разных таблиц ... поэтому, если activerecord используется в качестве модели, то любой из них должен будет втиснуть весь логический код в контроллер (который является довольно популярный в некоторых php-фреймворках), что затрудняет тестирование или взлом модели activerecord, так что она выполняет операции с базой данных не только над таблицей, с которой она связана, но также и над другими связанными таблицами ...

Итак, что же такого хорошего в злоупотреблении (IMHO) activerecord, как в модели архитектурного шаблона MVC?

Answer 1

Мартин Фаулер описал этот шаблон в Patterns of Enterprise Application Architecture вместе с двумя другими шаблонами или архитектурами. Эти шаблоны хороши для разных ситуаций и разной степени сложности.

Если вы хотите только простые вещи, вы можете использовать Transaction Script. Это архитектура, которую вы видели на многих старых страницах ASP и PHP, где один скрипт содержал бизнес-логику, логику доступа к данным и логику представления. Это быстро разваливается, когда все становится сложнее.

Следующее, что вы можете сделать, это добавить некоторое разделение между презентацией и моделью. Это активная запись. Модель все еще привязана к базе данных, но у вас немного больше гибкости, потому что вы можете повторно использовать свою модель / доступ к данным между представлениями / страницами / чем угодно. Это не так гибко, как могло бы быть, но в зависимости от вашего решения для доступа к данным оно может быть достаточно гибким. Фреймворки, подобные CSLA в .Net, имеют много аспектов из этого паттерна (я думаю, что Entity Framework тоже выглядит слишком похоже на это). Он по-прежнему может справиться со многими сложностями, не становясь необслуживаемым.

Следующим шагом является разделение вашего уровня доступа к данным и вашей модели. Это обычно требует хорошего ИЛИ картографа или большой работы. Так что не все хотят идти по этому пути. Множество методологий, таких как доменное проектирование, описывают этот подход.

Так что это все зависит от контекста. Что вам нужно и какое лучшее решение. Я даже до сих пор иногда использую транзакции-скрипт для простого одноразового кода.

Answer 2

Я много раз говорил, что использование Active Record (или ORM, которая почти такая же) в качестве бизнес-моделей не является хорошей идеей. Позвольте мне объяснить:

Тот факт, что PHP является открытым исходным кодом, свободен (и вся эта длинная история ...), предоставляет ему огромное сообщество разработчиков, разливающих код на форумы, такие сайты, как GitHub, код Google и так далее. Вы можете считать это хорошей вещью, но иногда это не так хорошо. Например, предположим, что вы сталкиваетесь с проектом и хотите использовать среду ORM для решения вашей проблемы, написанной на PHP, ну ... у вас будет много вариантов на :

• Учение
• Propel
• QCodo
• оцепенения
• RedBean

И этот список можно продолжать и продолжать. Новые проекты создаются регулярно. Итак, представьте, что вы создали полноценный фреймворк и даже генератор исходного кода на основе этого фреймворка. Но вы не размещали бизнес-классы, потому что, в конце концов, «зачем писать те же классы снова?». Время идет, и новая платформа ORM выпущена, и вы хотите переключиться на новую ORM, но вам придется модифицировать почти каждое клиентское приложение, используя прямую ссылку на вашу модель данных.

Суть в том, что Active Record и ORM должны находиться на уровне данных вашего приложения. Если вы смешаете их с уровнем представления, вы можете столкнуться с проблемами, подобными тому, который я только что положил.

Слушайте мудрые слова Мендельта: читайте Мартина Фаулера. Он написал много книг и статей по ОО-дизайну и опубликовал хороший материал на эту тему. Кроме того, вы можете рассмотреть Anti-Patterns , а точнее - Vendor Lock In , что и происходит, когда мы делаем наше приложение зависимым от сторонних инструментов. Наконец, я написал это сообщение в блоге, рассказывающее о той же проблеме, поэтому, если хотите, проверьте его.

Надеюсь, мой ответ пригодился.

Answer 3

Отличительной особенностью использования Rails ActiveRecord в качестве модели в MVC является то, что он предоставляет вам автоматический ORM (Object Relational Mapper) и простой способ создания ассоциаций между моделями. Как вы указали, иногда может не хватать MVC.

Поэтому, для какой-то сложной транзакции, включающей много моделей, я бы предложил использовать Presenter между вашим контроллером и вашими моделями ( Rails Presenter Pattern ). Presenter объединит ваши модели и транзакционную логику и останется легко тестируемым. Вы определенно хотите стремиться сохранить всю свою бизнес-логику в своих моделях или презентаторах и вне своих контроллеров ( Skinny Controller, Fat Model ).