ActiveRecord - плохая практика?

Question

Я начинаю новый проект, и недавно я обнаружил activerecord проекта замка, который выглядит как БОЛЬШОЕ решение, но в то же время он выглядит как нечто необычное. Мне было интересно, это чувство приходит от изучения чего-то нового (и я должен просто привыкнуть к нему) или это действительно плохая практика?

Answer 1

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

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

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

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

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

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

Answer 2

ActiveRecord - это шаблон проектирования, впервые названный Мартином Фаулером в Шаблоны архитектур корпоративных приложений . Он довольно распространен и широко используется в популярной платформе Ruby Rails.

Это контрастирует с более привычным стилем разработки в мире .Net, который заключается в использовании DAO, и это, возможно, объясняет, почему вам некомфортно.

Предложение: прочитайте исходный код некоторых приложений Ruby on Rails, похожих на ваши собственные проекты, и оцените, как вам нравится стиль дизайна, возникающий в результате интенсивного использования ActiveRecord.

Answer 3

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

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

Answer 4

Я думаю, что ActiveRecord не имеет ничего общего с Каслом, и, следовательно, ответы на этот вопрос Соответствует ли шаблон ActiveRecord принципам разработки SOLID / поощряет его?

Answer 5

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

User.Service.Save(user);

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

Answer 6

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

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

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

Answer 7

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