Является ли ActiveRecord плохой практикой?

Частью того, что мне показалось странным в использовании ActiveRecord, было наследование от ActiveRecordBase<T> и наличие всех этих методов персистентности в вашем объекте (Save и так далее).

А оказывается не надо! Вместо того, чтобы сказать:

[ActiveRecord]
class Customer : ActiveRecordBase<Customer> { }

Вы можете просто иметь

[ActiveRecord]
class Customer : inherit from whatever you want { }

а затем используйте ActiveRecordMediator<Customer>. Он имеет в основном те же статические методы, что и ActiveRecordBase<T>, но таким образом вам не нужно загромождать ими вашу объектную модель. Если вам не нужны различные обработчики событий защищенных методов в ActiveRecordBase<T>, это может упростить задачу.

Это не плохое решение, но у него есть свои недостатки.

В «Шаблонах архитектуры корпоративных приложений» Мартин Фаулер описывает несколько способов разработки приложений, построенных на основе базы данных. Эти методы отличаются способом отделения приложения от базы данных. Он также описывает, что большее разъединение делает возможными более сложные приложения. Active Record описывается как способ разработки более простых приложений, но для приложений с более сложным поведением вам нужна модель домена, независимая от базы данных, и что-то вроде объектно-реляционного преобразователя между ними.

ActiveRecord очень хорошо работает в Ruby, но его нелегко перенести на все языки. Центральным достижением AR является метафора table=class, row=instance. В Ruby это получается довольно элегантно, потому что классы также являются объектами. В других языках классы обычно представляют собой особый вид конструкции, и тогда вам нужно пройти через всевозможные обручи, чтобы заставить их работать правильно. Это убирает некоторые из естественных ощущений, которые есть в Ruby.

Смешение доменного объекта с сервисным уровнем — самая большая плохая практика (если вы считаете это плохой практикой). В конечном итоге вы вызываете user.Save(), что означает, что если вы хотите изменить свой ORM, вы полагаетесь на этот шаблон. Две альтернативы - это слой, также известный как набор фасадных классов для выполнения ваших операций CRUD, или поместить это внутри объекта домена как что-то вроде

User.Service.Save(user);

Если вы используете .NET, то ActiveRecord, очевидно, основан на ActiveRecord, Coolstorage, Subsonic и несколько других.

Нет, это не плохая практика. Даже в .NET сейчас это довольно хорошо зарекомендовавший себя шаблон. SubSonic (http://subsonicproject.com) и LINQ to SQL также используют шаблон.

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

Это не означает, что это хорошее решение для всех систем. Для больших и сложных систем вы, вероятно, захотите иметь меньшую связь с хранилищем данных.

Я думаю, что ActiveRecord не имеет ничего общего с Castle, и поэтому ответы на этот вопрос -solid-design-principles">Соответствует ли шаблон ActiveRecord принципам проектирования SOLID/поощряет их? Многим может быть более понятно.