Почему вся Активная Рекордная ненависть? [закрытый]

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

Проблема с ActiveRecord состоит в том, что запросы, которые он автоматически генерирует для Вас, могут вызвать проблемы производительности.

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

Проблема, которую я вижу с Активными Записями, что это всегда примерно одно таблица. Это хорошо, пока Вы действительно работаете только с, что одна таблица, но когда Вы работаете с данными в большинстве случаев, у Вас будет некоторое соединение где-нибудь.

Да, соединение обычно хуже, чем никакое соединение во всем когда дело доходит до производительности, но , соединение обычно лучше, чем "поддельное" соединение первым чтением целая таблица A и затем использование полученной информации, чтобы считать и отфильтровать таблицу B.

Я люблю способ, которым SubSonic делает один столбец только вещь.
Или

DataBaseTable.GetList(DataBaseTable.Columns.ColumnYouWant)

, или:

Query q = DataBaseTable.CreateQuery()
               .WHERE(DataBaseTable.Columns.ColumnToFilterOn,value);
q.SelectList = DataBaseTable.Columns.ColumnYouWant;
q.Load();

, Но Linq все еще король когда дело доходит до ленивой загрузки.

@BlaM: Иногда я выгонял, реализовал активную запись для результата соединения. Должна не всегда быть Таблица отношения <-> Активная Запись. Почему не "Результат оператора Join" <-> Активная Запись?

вопрос об Активном Рекордном шаблоне разработки. Не orm Инструмент.

исходный вопрос отмечен с направляющими и относится к Twitter, который создается в Ruby on Rails. Платформа ActiveRecord в направляющих является реализацией Активного Рекордного шаблона разработки Fowler.

Я всегда находил, что ActiveRecord хорош для быстрых основанных на CRUD приложений, где Модель является относительно плоской (как в, не много иерархий классов). Однако для приложений со сложными иерархиями OO, DataMapper является, вероятно, лучшим решением. В то время как ActiveRecord принимает 1:1 отношение между Вашими таблицами и Вашими объектами данных, такие отношения становятся громоздкими с более сложными доменами. В его книга по шаблонам , Martin Fowler указывает, что ActiveRecord склонен ломаться при условиях, где Ваша Модель довольно сложна, и предлагает DataMapper как альтернатива.

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

способ, которым я делаю это, состоит в том, чтобы иметь "доменные" объекты, к которым получают доступ Ваши контроллеры через эти DataMapper (или "уровень служб") классы. Они непосредственно не зеркально отражают базу данных, но действуют как Ваше представление OO для некоторого реального объекта. Скажите, что Вы имеете Пользовательский класс в своем домене и должны иметь ссылки на, или наборы других объектов, уже загруженных при получении того Пользовательского объекта. Данные могут прибывать из многих различных таблиц, и шаблон ActiveRecord может сделать их действительно трудно.

Вместо того, чтобы загрузить Пользовательский объект непосредственно и получить доступ к данным с помощью API стиля ActiveRecord, код контроллера получает Пользовательский объект путем называния API UserMapper.getUser () методом, например. Именно тот картопостроитель ответственен за загрузку любых связанных объектов от их соответствующих таблиц и возврата завершенного Пользовательского объекта "домена" вызывающей стороне.

По существу, Вы просто добавляете другой слой абстракции для создания кода более managable. Содержат ли Ваши классы DataMapper необработанный пользовательский SQL, или звонит в API уровня абстракции данных, или даже получите доступ к шаблону ActiveRecord сами, действительно не имейте значения для кода контроллера, который получает хороший, заполненный Пользовательский объект.

Так или иначе, это - то, как я делаю это.

Главное, которое я видел относительно жалоб на Активную Запись, состоит в том, что при создании модели вокруг таблицы, и Вы выбираете несколько экземпляров модели, Вы в основном делаете "выбор * от...". Это хорошо для редактирования записи или отображения записи, но если Вы хотите, скажем, отобразить список городов для всех контактов в Вашей базе данных, Вы могли сделать "избранный Город от..." и только получить города. Выполнение этого с Активной Записью потребовало бы, чтобы Вы выбрали все столбцы, но только использовали Город.

, Конечно, переменные реализации обработают это по-другому. Тем не менее, это - одна проблема.

Теперь, можно обойти это путем создания новой модели для определенной вещи, которую Вы пытаетесь сделать, но некоторые люди утверждали бы, что это - больше усилия, чем преимущество.

Меня, я рою Активную Запись.:-)

HTH

Я думаю там, что действительно ли вероятным является совсем другой набор причин между тем, почему люди "ненавидят" на ActiveRecord и что является "неправильным" с ним.

По проблеме ненависти, существует много яда к чему-либо связанные направляющие. До что не так с ним, вероятно, что это похоже на всю технологию и существуют ситуации, где это - хороший выбор и ситуации, где существует лучший выбор. Ситуация, где Вы не добираетесь для использования в своих интересах большинства функций направляющих ActiveRecord, по моему опыту, состоит в том, где база данных плохо структурирована. Если Вы получаете доступ к данным без первичных ключей с вещами, которые нарушают первую нормальную форму, где существует много хранимых процедур, требуемых получить доступ к данным, Вы - более обеспеченное использование чего-то, что является больше просто оберткой SQL. Если Ваша база данных относительно хорошо структурирована, ActiveRecord позволяет Вам использовать в своих интересах это.

Для добавления к теме ответа комментаторам, которые говорят, вещи тверды в ActiveRecord с возражением фрагмента кода

, @Sam McAfee Заявляет, что Вы имеете Пользовательский класс в своем домене и должны иметь ссылки на, или наборы других объектов, уже загруженных при получении того Пользовательского объекта. Данные могут прибывать из многих различных таблиц, и шаблон ActiveRecord может сделать их действительно трудно.

user = User.find(id, :include => ["posts", "comments"])
first_post = user.posts.first
first_comment = user.comments.first

При помощи включать опции, ActiveRecord позволяет Вам переопределить лениво загружающееся поведение по умолчанию.

Попробуйте установить полиморфные отношения "многие ко многим". Не просто. Особенно, если вы не используете ИППП.

Мой длинный и поздний ответ, даже не полный, но хорошее объяснение, ПОЧЕМУ я ненавижу этот шаблон, мнения и даже некоторые эмоции:

1) краткая версия: Active Record создает «тонкий слой » из « сильной связи » между базой данных и кодом приложения. Что не решает ни логических, ни каких-либо проблем, вообще никаких проблем. IMHO он не предоставляет НИКАКОГО ЗНАЧЕНИЯ, за исключением некоторого синтаксического сахара для программиста (который затем может использовать «объектный синтаксис» для доступа к некоторым данным, существующим в реляционной базе данных). Усилия по созданию некоторого комфорта для программистов должны (ИМХО ... ) лучше вкладываться в инструменты доступа к базам данных низкого уровня, например, некоторые варианты простого, легкого, простого hash_map get_record (string id_value, string table_name, string id_column_name = "id") и подобных методов (конечно, концепции и элегантность сильно различаются в зависимости от используемого языка).

2) длинная версия: в любых проектах, основанных на базе данных, где у меня был «концептуальный контроль», я избегал AR, и это было хорошо. Я обычно строю многоуровневую архитектуру (вы рано или поздно все же делите свое программное обеспечение на слои, по крайней мере, в проектах среднего и большого размера):

A1) сама база данных, таблицы, отношения и даже некоторая логика, если СУБД позволяет это (MySQL теперь тоже вырос)

A2) очень часто есть нечто большее, чем просто хранилище данных: файловая система (блобы в базе данных не всегда хорошее решение ...), унаследованные системы (представьте себе, «как» они будут доступны, возможно множество разновидностей .. но не в этом суть…)

B) уровень доступа к базе данных (на этом уровне инструменты, методы, помощники для легкого доступа к данным в база данных очень приветствуется, но AR не предоставляет здесь никакой ценности, кроме некоторого синтаксического сахара)

C) уровень объектов приложения: «объекты приложения» иногда являются простыми строками таблицы в базе данных, но в большинстве случаев они в любом случае объединяют объекты и имеют некоторую более высокую логику, поэтому вкладывать время в объекты AR на этом уровне просто бесполезно, тратя драгоценное время кодировщиков, потому что «реальная ценность», «высшая логика» в любом случае эти объекты должны быть реализованы поверх объектов AR - с AR и без! И, например, зачем вам абстракция «объектов записей журнала»? Код логики приложения записывает их, но должен ли он иметь возможность обновлять или удалять их? звучит глупо, и App :: Log («Я - сообщение журнала») в некоторой степени проще в использовании, чем le = new LogEntry (); le.time = сейчас (); le.text = "Я - сообщение журнала"; le.Insert (); . И, например: использование «объекта записи журнала» в представлении журнала в вашем приложении будет работать для 100, 1000 или даже 10000 строк журнала, но рано или поздно вам придется оптимизировать - и я уверен, что в большинстве случаев вы просто используйте этот небольшой красивый оператор SQL SELECT в логике своего приложения (который полностью разрушает идею AR ...) вместо того, чтобы оборачивать этот небольшой оператор в жесткие фиксированные рамки идеи AR с большим количеством кода, обертывающего и скрывающего его. Время, которое вы потратили на написание и / или построение кода AR, можно было бы вложить в гораздо более умный интерфейс для чтения списков записей журнала (во многих случаях пределом нет). Кодеры должны осмелиться изобретать новые абстракции , чтобы реализовать логику своего приложения, которая соответствует предполагаемому приложению, и не тупо повторно реализовывать глупые шаблоны , которые кажутся хорошими на первый взгляд!

D ) логика приложения - реализует логику взаимодействия объектов и создания, удаления и перечисления (!) объектов логики приложения (НЕТ, эти задачи редко следует закреплять в самих объектах логики приложения: говорит ли вам лист бумаги на вашем столе имена и расположение всех других листов в вашем офисе? Забудьте "статические" методы для перечисления объектов, это глупо, плохой компромисс, созданный для того, чтобы приспособить человеческий образ мышления к мышлению AR

E) пользовательский интерфейс - ну, в следующих строках я напишу очень, очень, очень субъективно, но по моему опыту, проекты, основанные на AR, часто игнорировали UI-часть приложения - время тратилось на создание непонятных абстракций. В конце концов, такие приложения отнимали у программистов много времени и ощущались как приложения от кодеров для кодеров, ориентированные на технические аспекты как внутри, так и снаружи. Кодировщики чувствуют себя хорошо (наконец-то тяжелая работа сделана, все закончено и правильно, в соответствии с концепцией на бумаге ...), а заказчики «просто должны понять, что так должно быть», потому что это «профессионально» .. ладно, извините, я отвлекся; -)

Ну, надо признать, это все субъективно, но это мой опыт (за исключением Ruby on Rails, он может быть другим, и у меня нулевой практический опыт использования этого подхода).

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

По прошествии многих лет (десять лет активного опыта разработки), всякий раз, когда заказчик упоминает «активную схему записи», у меня звонит сигнал тревоги. Я научился пытаться вернуть их к той важной фазе зачатия , дать им подумать дважды, попытаться показать свои концептуальные слабости или просто избегать их, если они не различают (в конце концов, вы знаете, заказчик, который еще не знает, чего он хочет, возможно, даже думает, что знает, но не знает, или пытается бесплатно передать концептуальную работу МНЕ, стоит мне много драгоценных часов, дней, недель и месяцев моего времени, жить тоже короче ...).

Итак, наконец: ЭТО ВСЕ - вот почему я ненавижу этот глупый «шаблон активной записи», и я люблю и буду избегать его, когда это возможно.

РЕДАКТИРОВАТЬ : Я бы даже назвал это без шаблона. Это не решает никаких проблем (шаблоны не предназначены для создания синтаксического сахара). Это создает много проблем: корень всех его проблем (упомянутых во многих ответах здесь ..) заключается в том, что он просто скрывает старый добрый, хорошо разработанный и мощный SQL за интерфейсом, который определяется определением шаблонов чрезвычайно ограничен.

Этот шаблон заменяет гибкость синтаксическим сахаром!

Подумайте об этом,