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

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

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

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

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

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

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

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

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

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

• Доктрина
• Продвигать
• QCodo
• Оцепенение
• Красная фасоль

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

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

Послушайте мудрые слова @Mendelt: прочтите Мартина Фаулера. Он опубликовал много книг и статей по объектно-ориентированному дизайну и опубликовал несколько хороших материалов по этой теме. Кроме того, вы можете захотеть изучить Антипаттерны, а точнее Поставщик заблокирован, что происходит, когда мы делаем наше приложение зависимым от сторонних инструментов. Наконец, я написал сообщение в блоге это, посвященное той же проблеме, поэтому, если хотите, проверьте его.

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