Почему все Active Record ненавидит?

голоса
101

Как я узнаю все больше и больше о ООП, и приступить к реализации различных шаблонов дизайна, я продолжаю возвращаться к случаям , когда люди ненавидели на Active Record .

Часто люди говорят , что это не очень хорошо масштабируется (со ссылкой на Twitter в качестве основного примера) - но на самом деле никто не объясняет , почему он не очень хорошо масштабируется; и / или , как достичь плюсов АРА без недостатков (через аналогичный , но другой шаблон?)

Надеюсь, это не превратится в священной войне о шаблонах проектирования - все, что я хочу знать **** **** конкретно, что случилось с Active Record.

Если это не очень хорошо масштабируется, почему бы и нет?

Какие проблемы у него есть?

Задан 11/08/2008 в 14:30
источник пользователем
На других языках...                            


14 ответов

голоса
2

Главное, что я видел в отношении жалоб на Active Record, что при создании модели вокруг стола, и вы выберите несколько экземпляров модели, вы в основном делаете «select * from ...». Это нормально для редактирования записи или отображения записи, но если вы хотите, скажем, отобразить список городов для всех контактов в вашей базе данных, можно сделать «выбрать город из ...» и получить только города , Делать это с Active Record требует, чтобы вы выбрать все столбцы, но только с помощью города.

Конечно, различные реализации будут обращаться с этим по-разному. Тем не менее, это один вопрос.

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

Я, я копаю Active Record. :-)

НТН

Ответил 11/08/2008 в 15:22
источник пользователем

голоса
0

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

Да, присоединиться обычно хуже , чем не вступать вообще , когда речь идет о производительности, но присоединиться , как правило , лучше , чем «подделка» присоединиться сначала читает всю таблицу А , а затем , используя полученную информацию для чтения и фильтр таблицы B.

Ответил 11/08/2008 в 15:46
источник пользователем

голоса
1

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

DataBaseTable.GetList(DataBaseTable.Columns.ColumnYouWant)

, или:

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

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

Ответил 11/08/2008 в 18:50
источник пользователем

голоса
90

Там в ActiveRecord шаблон дизайна и ActiveRecord ОРМ библиотеки Rails , и есть также тонну нокаут-офф для .NET и других языках.

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

Я знаком только с ActiveRecord Rails', я постараюсь рассмотреть все жалобы, которые были подняты в контексте его использования.

@BlaM

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

Код:

class Person
    belongs_to :company
end
people = Person.find(:all, :include => :company )

Это генерирует SQL с LEFT JOIN companies on companies.id = person.company_id, и автоматически генерирует связанные компании объекты , так что вы можете сделать , people.first.companyи это не нужно попасть в базу данных , так как данные уже присутствуют.

@ pix0r

Врожденная проблема с Active Record, что запросы к базе данных генерируются автоматически и выполняются для заполнения объектов и изменять записи базы данных

Код:

person = Person.find_by_sql("giant complicated sql query")

Это не рекомендуется, так как это некрасиво, но и для тех случаев, когда вы просто и просто нужно написать сырой SQL, это легко сделать.

Sullivan @ Тим

... и вы выберите несколько экземпляров модели, вы в основном делаете «select * from ...»

Код:

people = Person.find(:all, :select=>'name, id')

Это будет только выбрать имя и ID столбцов из базы данных, все другие «атрибуты» в картографическим объектам будет просто ноль, если вы вручную перезагрузить этот объект, и так далее.

Ответил 11/08/2008 в 20:02
источник пользователем

голоса
1

@BlaM: Иногда я justed осуществил активную запись для результата объединения. Не всегда должны быть отношения Таблица <-> Active Record. Почему не "результат Join заявление" <-> Active Record?

Ответил 11/08/2008 в 20:14
источник пользователем

голоса
0

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

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

Ответил 15/08/2008 в 13:32
источник пользователем

голоса
51

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

Я обнаружил, что это правда, на практике. В тех случаях, когда у вас есть много наследования в домене, труднее карта наследования к РСУБДУ, чем сопоставить ассоциации или композицию.

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

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

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

Во всяком случае, вот как я это делаю.

Ответил 26/08/2008 в 17:10
источник пользователем

голоса
0

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

Ответил 26/08/2008 в 17:31
источник пользователем

голоса
3

Речь идет об активном шаблоне дизайна записи. Не ОРМ инструмент.

Оригинальный вопрос помечается с рельсами и относится к Twitter, который встроен в Ruby On Rails. Структура ActiveRecord в Rails является реализацией активного шаблона дизайна Записи Фаулера.

Ответил 26/08/2008 в 18:19
источник пользователем

голоса
11

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

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

Чтобы добавить тему в ответ на комментатор, которые говорят вещи трудно в ActiveRecord с фрагмент кода репликой

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

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

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

Ответил 22/09/2008 в 20:35
источник пользователем

голоса
0

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

Ответил 20/07/2009 в 12:39
источник пользователем

голоса
7

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

1) короткая версия: Active Record создает « тонкий слой » из « сильной связи » между базой данных и кода приложения. Который не решает ни одного логических, нет каких бы то ни-проблем, никаких проблем вообще. ИМХО это не дает никакого значения, за исключением некоторого синтаксического сахара для программиста (который затем может использовать «объект синтаксис» , чтобы получить доступ к некоторым данным, которые существуют в реляционной базе данных). Усилия , чтобы создать некоторый комфорт для программистов должны (имхо ...) лучше быть инвестированы в инструментах доступа к базам данных низкого уровня, например , некоторые вариации простых, легких, простых 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! И, например, почему вы хотели бы иметь абстракции «Log объекты входа»? App логики код записывает их, но это должно иметь возможность обновлять или удалять их? звучит глупо, и App::Log("I am a log message")это несколько магнитуд проще в использовании , чемle=new LogEntry(); le.time=now(); le.text="I am a log message"; le.Insert();, И, например: с помощью «Log ввода объекта» в окне просмотра журнала в приложении будет работать на 100, 1000 или даже 10000 линий журнала, но рано или поздно вам придется оптимизировать - и я держал пари , в большинстве случаев, вы просто использовать этот небольшой красивый SQL SELECT заявление в ваше приложение логики (который полностью разрушает идею AR ..), вместо того , чтобы упаковка , что небольшое заявление в жестких фиксированных идей кадров AR с большим количеством кода упаковки и скрывает это. Время , которое вы впустую с письменной форме и / или строительного кодекса АР могли бы быть инвестированы в гораздо более умный интерфейс для чтения списков лог-записей (много, много способов, небо это предел). Программисты должны осмелятся придумать новые абстракции , чтобы понять их логику приложения , которые соответствуют предполагаемому применению, а не тупо повторно реализовать глупые модели, Что звук хороший на первый взгляд!

D) логика приложения - реализует логику взаимодействующих объектов и создания, удаления и перечисления () логики приложения объектов (NO, эти задачи редко должны быть закреплены в самой логики приложения объектов: это лист бумаги на столе сказать! вы имена и расположение всех других листов в вашем офисе? забыть «статические» методы для перечисления объектов, тот глупый, плохой компромисс, созданный, чтобы сделать человеческий образ мышления вписываться [некоторые-не-все-AR-каркасного как -] AR мышления)

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

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

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

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

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

EDIT : Я бы даже назвал это No-шаблон. Это не решает любую проблемы (модели не предназначены для создания синтаксического сахара). Это создает множество проблем: корень всех его проблем (упоминается во многих ответах здесь ..) в том, что она просто скрывает старый добрый хорошо развитый и мощный SQL за интерфейс , который по определению моделей крайне ограниченным.

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

Подумайте об этом, что проблема не AR решить для вас?

Ответил 27/11/2009 в 08:02
источник пользователем

голоса
1

Я буду говорить о Active Record, как шаблон проектирования, я не видел ROR.

Некоторые разработчики ненавидят Active Record, потому что они читают умные книги о написании чистый и аккуратный код, и эти книги утверждает, что активная запись нарушает единый принцип resposobility, нарушает DDD исключает, что объект домена должен быть Устойчивые невежественные, и многие другие правила, от такого рода книг ,

Вторые объекты вещь домена в Active Record, как правило, 1-к-1 с базой данных, что может рассматриваться как ограничение в какой-системах (п-уровня в основном).

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

Ответил 13/06/2011 в 06:26
источник пользователем

голоса
5

Некоторые сообщения получают меня путают. Некоторые ответы собираются «ОРМ» против «SQL» или что-то в этом роде.

Дело в том, что AR просто шаблон упрощения программирования, где вы воспользоваться вашей предметной области, чтобы написать там код доступа к базе данных.

Эти объекты, как правило, бизнес-атрибуты (свойства бина) и некоторое поведение (методы, которые обычно работают на эти свойства).

AR просто говорит «добавить некоторые методы этих объектов предметной области» к задачам базы данных, связанных с.

И я должен сказать, что от моего мнения и опыта, что мне не нравится шаблон.

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

Для меня реальная проблема только с ООП концерна. AR модель заставляет вас каким-то образом добавить зависимость от вашего объекта infraestructure объектов. Эти объекты infraestructure пусть объект домена для запроса базы данных с помощью методов, предложенных AR.

Я всегда говорил, что два слоя являются ключевыми для успеха проекта. Уровня службы (где логика Bussiness находится или может быть экспортирована через какой-то Remoting технологии, как веб-служб, к примеру) и слой домена. На моем взгляде, если мы добавим некоторую зависимость (на самом деле не нужно) к объектам домена слоя для разрешения шаблона AR, наши объекты домена будут сложнее, чтобы поделиться с другими слоями или (редко) внешними приложениями.

Реализация Spring Roo АР интересен тем, что он не зависит от самого объекта, но в некоторых файлах AspectJ. Но если в дальнейшем вы не хотите работать с Им и должен реорганизовать проект, методы AR будут осуществляться непосредственно в ваших объектах домена.

Другая точка зрения. Представьте себе, что мы не используем реляционную базу данных для хранения наших объектов. Представьте себе приложение хранит свои объекты домена в базе данных NoSQL или просто в файлах XML, например. Мы бы реализовать методы, которые делают эти задачи в наших объектах предметной области? Я не думаю, что так (например, в случае XM, мы могли бы добавить зависимости, связанные с XML наших объектов предметной области ... Действительно грустно, я думаю). Почему же тогда мы должны реализовать реляционные методы БД в предметной области, как говорит модель Ar?

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

Ответил 25/08/2011 в 08:42
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more