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

Question

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

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

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

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

Answer 1

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

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

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

Следующий шаг - это разделение вашего уровня доступа к данным и вашей модели. Для этого обычно требуется хороший OR-блок или большая работа. Поэтому не каждый хочет идти этим путем. Методы Lot, такие как дизайн, основанный на доменах, придерживаются такого подхода.

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

Answer 2

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

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

Answer 3

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

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

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

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

Нижняя строка, активная запись и ORM предназначены для того, чтобы быть в слое данных вашего приложения, если вы смешиваете их с уровнем презентации, вы можете столкнуться с такими проблемами, как этот пример, который я только что положил.

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

Надеюсь, что мой ответ был полезен.