Чому всі Active Record ненавидять? [зачинено]

Коли я все більше і більше дізнаюся про OOP і починаю впроваджувати різні шаблони дизайну, я все більше повертаюся до випадків, коли люди ненавидять Active Record .

Часто люди кажуть, що це не так добре (цитуючи Twitter як головний приклад), - але ніхто насправді не пояснює, чому він не масштабується; та / або як досягти плюсів AR без мінусів (за аналогічною, але різною схемою?)

Сподіваємось, це не перетвориться на святу війну щодо моделей дизайну - все, що я хочу знати, - це ****, ****, що не так з Active Record.

Якщо вона не масштабується добре, чому б ні?

Які ще проблеми це має?

Існує ActiveRecord Шаблон дизайну та ActiveRecord Бібліотека ORM Rails , а також є безліч статей для .NET та інших мов.

Це все різні речі. Вони здебільшого слідують такому шаблону дизайну, але розширюють і модифікують його різними способами, тож перш ніж хтось скаже "ActiveRecord Sucks", його потрібно кваліфікувати, сказавши "який ActiveRecord, там купи?"

Мені лише знайомий Rails 'ActiveRecord, я спробую розглянути всі скарги, які були звернені в контексті його використання.

@BlaM

Проблема, яку я бачу з Active Records, полягає в тому, що це завжди лише одна таблиця

Код:

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, це легко зробити.

@Tim Sullivan

... і ви вибираєте кілька примірників моделі, ви в основному робите "select * from ..."

Код:

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

Це дозволить вибрати лише стовпці імен та ідентифікаторів із бази даних, усі інші "атрибути" в об'єктах, що відображаються, просто будуть нульовими, якщо ви не вручну перезавантажите цей об'єкт тощо.

Я завжди вважав, що ActiveRecord хороший для швидких програм на основі CRUD, де Модель порівняно рівна (як, наприклад, не багато ієрархій класів). Однак для додатків зі складною ієрархією ОО, DataMapper - це, мабуть, краще рішення. Хоча ActiveRecord передбачає співвідношення 1: 1 між вашими таблицями та вашими об'єктами даних, такі відносини стають непростими для складніших доменів. У своїй книзі про зразки Мартін Фаулер вказує, що ActiveRecord має тенденцію руйнуватися в умовах, коли ваша модель досить складна, і пропонує DataMapper як альтернативу.

Я визнав це правдою на практиці. У випадках, коли у вас є багато спадку у вашому домені, важче віднести спадщину до вашої RDBMS, ніж це для відображення асоціацій чи складу.

Як я це роблю, - це мати "доменні" об'єкти, до яких звертаються контролери за допомогою цих класів DataMapper (або "рівень обслуговування"). Вони не відображають безпосередньо базу даних, але служать вашим представництвом ОО для якогось об'єкта реального світу. Скажімо, у вас є клас користувача у вашому домені, і вам потрібно мати посилання або колекції інших об'єктів, які вже завантажені під час отримання цього об’єкта користувача. Дані можуть надходити з багатьох різних таблиць, і шаблон ActiveRecord може зробити це дуже важким.

Замість завантаження об'єкта User безпосередньо та доступу до даних за допомогою API стилю ActiveRecord, код контролера отримує об’єкт User, викликаючи, наприклад, API методу UserMapper.getUser (). Саме той картограф відповідає за завантаження будь-яких асоційованих об'єктів із відповідних таблиць та повернення завершеного користувальницького об’єкта "домен" абоненту.

По суті, ви просто додаєте ще один шар абстракції, щоб зробити код більш керованим. Незалежно від того, чи ваші класи DataMapper містять необроблений користувальницький SQL, або дзвінки до API рівня абстрагування даних або навіть доступ до самого шаблону ActiveRecord, насправді не має значення для коду контролера, який отримує приємний заселений користувальницький об’єкт.

У всякому разі, саме так я це роблю.

Я думаю, що, мабуть, існує дуже різний набір причин між тим, чому люди "ненавидять" ActiveRecord, і тим, що з цим "не так".

Що стосується ненависті, то існує багато отрути щодо всього, що стосується Рейлів. Що стосується того, що з цим не так, то, ймовірно, це як у всіх технологій, і є ситуації, коли це вдалий вибір і ситуації, коли є кращий вибір. На моєму досвіді ситуація, коли ви не можете скористатися більшістю можливостей Rails 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 не надає жодної цінності, за винятком деякого синтаксичного цукру для програміста (який може потім використовувати "об'єктний синтаксис" для доступу до деяких даних, що існують у реляційній базі даних). Намагання створити певний комфорт для програмістів (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("I am a log message")деякі величини простіші у використанні, ніжle=new LogEntry(); le.time=now(); le.text="I am a log message"; le.Insert();. І наприклад: використання "об’єкта входу в журнал" у режимі перегляду журналу у вашій програмі буде працювати для 100, 1000 чи навіть 10000 рядків журналу, але рано чи пізно вам доведеться оптимізувати - і я ставлю ставку в більшості випадків, ви просто використовуйте цей невеликий красивий оператор SQL SELECT в логіці програми (що повністю порушує ідею AR ..), замість того, щоб загортати це невелике твердження у жорсткі фіксовані рамки ідеї AR з великою кількістю коду і приховувати його. Час, який ви витратили на написання та / або створення AR-коду, можна було б інвестувати в набагато розумніший інтерфейс для читання списків записів журналів (багато, багато способів, небо - це межа). Кодери повинні наважитися вигадувати нові абстракції, щоб реалізувати свою логіку застосування, що відповідає передбачуваному додатку, а не тупо повторно реалізовувати дурні шаблони, це звучить добре з першого погляду!

Г) логіка програми - реалізує логіку взаємодіючих об'єктів та створює, видаляючи та перераховуючи (!) Об’єкти логіки програми (НІ, ці завдання рідко повинні бути закріплені в самих логічних об'єктах програми: чи говорить аркуш паперу на вашому столі ви назви та місця розташування всіх інших аркушів у вашому кабінеті? забудьте "статичні" методи перерахування об'єктів, дурний, поганий компроміс, створений для того, щоб людський спосіб мислення вписався в [якийсь не все-AR-каркас-подібний -] AR мислення)

Е) користувальницький інтерфейс - ну, те, що я напишу в наступних рядках, дуже, дуже, дуже суб'єктивно, але, на мій досвід, проекти, побудовані на AR, часто нехтують частиною програми інтерфейсу користувача - витрачали час на створення незрозумілих абстракцій . Врешті-решт такі програми витрачають багато кодерів часу і відчувають, що програми з кодерів для кодерів, технічно схильні всередині і зовні. Кодери відчувають себе добре (нарешті важка робота, все закінчено і правильно, згідно з концепцією на папері ...), а замовники "просто повинні навчитися, що це має бути таким", тому що це "професійно" .. ок, вибачте, я відволікаюсь ;-)

Ну, правда, це все суб'єктивно, але мій досвід (Ruby on Rails виключається, це може бути інакше, і я маю нульовий практичний досвід з таким підходом).

У платних проектах я часто чула вимогу почати зі створення деяких об'єктів "активного запису" як складового елемента для логіки додатків вищого рівня. На мій досвід, це помітно частобуло певним приводом для того, що у замовника (компанії, що розробляє програмне забезпечення в більшості випадків) не було хорошої концепції, великий погляд, огляд того, яким повинен бути продукт. Ці замовники думають у жорстких кадрах ("у проекті десять років тому він працював добре."), Вони можуть згуртовувати сутності, вони можуть визначати відносини між сутностями, вони можуть порушувати відносини даних та визначати базову логіку програми, але тоді вони зупиняються і передайте це вам, і подумайте, що все, що вам потрібно ... їм часто не вистачає повної концепції логіки програми, користувальницького інтерфейсу, зручності використання тощо, і так далі ... їм не вистачає великого погляду, і їм не вистачає любові до деталі, і вони хочуть, щоб ви дотримувались цього способу AR, тому що ... ну чому ж він працював у тому проекті років тому, він тримає людей зайнятих і мовчазних? Не знаю. Але "подробиці" відокремити чоловіків від хлопців, або .. як було оригінальним слоганом реклами? ;-)

Через багато років (десять років активного досвіду розробки) кожен раз, коли клієнт згадує про "активну схему запису", дзвонить мій сигнал тривоги. Я навчився намагатися повернути їх до тієї суттєвої концептуальної фази , нехай подумають двічі, спробують показати свої слабкі уявлення або просто взагалі уникати їх, якщо вони нерозбірливі (врешті-решт, ти знаєш, замовник, який ще не робить цього знаю, що хоче, може, навіть думає, що знає, але ні, або намагається зовнішньо працювати з концепцією для мене безкоштовно, коштує мені багато дорогоцінних годин, днів, тижнів і місяців мого часу, жити занадто коротко ...)

Отже, нарешті: ЦЕ ВСЕ, чому я ненавиджу цей нерозумний "активний шаблон запису", і роблю і уникатиму його, коли це можливо.

EDIT : Я б навіть назвав це відсутнім зразком. Це не вирішує жодної проблеми (шаблони не призначені для створення синтаксичного цукру). Це створює багато проблем: корінь усіх його проблем (про які згадується в багатьох відповідях тут ..) полягає в тому, що він просто приховує старий добрий добре розвинений і потужний SQL за інтерфейсом, який за визначенням шаблонів надзвичайно обмежений.

Ця модель замінює гнучкість синтаксичним цукром!

Подумайте, яку проблему вирішує AR для вас?

Деякі повідомлення мене плутають. Деякі відповіді збираються на "ORM" проти "SQL" або щось подібне.

Справа в тому, що AR - це лише схема спрощення програмування, коли ви користуєтеся своїми об’єктами домену, щоб записати там код доступу до бази даних.

Ці об'єкти зазвичай мають ділові атрибути (властивості квасолі) та деяку поведінку (методи, які зазвичай працюють на цих властивостях).

AR просто каже "додати деякі методи до цих об'єктів домену" до завдань, пов'язаних з базою даних.

І я маю сказати, з моєї думки та досвіду, що модель мені не подобається.

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

Для мене справжня проблема полягає лише в турботі OOP. Зразок AR змушує вас якимось чином додати залежність від вашого об'єкта до об’єктів інфраструктури. Ці об’єкти інфраструктури дозволяють об’єкту домену запитувати базу даних методами, запропонованими AR.

Я завжди говорив, що два шари є ключовими для успіху проекту. Сервісний рівень (де логіка ділових ресурсів знаходиться або може бути експортований за допомогою якоїсь віддаленої технології, наприклад веб-служб) та доменний рівень. На мою думку, якщо ми додамо деякі залежності (не дуже потрібні) до об'єктів доменного шару для вирішення шаблону AR, наші об’єкти домену будуть складніше ділитися з іншими шарами або (рідкісними) зовнішніми програмами.

Реалізація AR Spring Spring Roo цікава тим, що вона не покладається на сам об’єкт, а на деякі файли AspectJ. Але якщо пізніше ви не хочете працювати з Roo і вам доведеться переробляти проект, методи AR будуть реалізовані безпосередньо у ваших доменних об'єктах.

Ще одна точка зору. Уявіть, що ми не використовуємо реляційну базу даних для зберігання наших об'єктів. Уявіть, що програма, наприклад, зберігає наші об’єкти домену у базі даних NoSQL або просто у файлах XML. Чи реалізували б ми методи, які виконують ці завдання в наших об’єктах домену? Я не думаю, що так (наприклад, у випадку XM, ми б додавали залежності, пов'язані з XML, до наших об’єктів домену ... Дуже сумно, я думаю). Чому тоді нам доводиться реалізовувати реляційні методи БД в об'єктах домену, як говорить шаблон Ar?

Підводячи підсумок, модель AR може здаватися простішою та хорошою для малих та простих програм. Але, коли у нас є складні та великі програми, я думаю, що класична шарувата архітектура - це кращий підхід.

Питання стосується структури дизайну Active Record. Не інструмент орми.

Оригінальне запитання позначене рейками і стосується Twitter, який побудований у Ruby on Rails. Рамка ActiveRecord в Rails - це реалізація схеми дизайну Fowler Active Record.

Головне, що я бачив щодо скарг на Active Record, це те, що коли ви створюєте модель навколо столу і вибираєте кілька екземплярів моделі, ви в основному робите "select * from ...". Це добре для редагування запису або показу запису, але якщо ви хочете, скажімо, відобразити список міст для всіх контактів у вашій базі даних, ви можете зробити "Вибрати місто з ..." і отримати лише міста . Для цього за допомогою Active Record потрібно буде вибрати всі стовпці, але використовувати лише місто.

Зрозуміло, різні реалізації будуть вирішувати це по-різному. Тим не менш, це одне питання.

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

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

HTH

Мені подобається, як SubSonic робить одне тільки стовпець.
Або

DataBaseTable.GetList(DataBaseTable.Columns.ColumnYouWant)

або:

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

Але Лінк все-таки король, коли справа стосується ледачих навантажень.

@BlaM: Іноді я використовував активний запис у результаті приєднання. Не завжди повинно бути співвідношення Таблиця <--> Активні записи. Чому б "Результат заяви про приєднання" <--> Активні записи?

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

Деякі розробники ненавидять Active Record, оскільки вони читають розумні книги про написання чистого та акуратного коду, і ці книги стверджують, що активний запис порушує принцип єдиної відповідальності, порушує правило DDD, що об’єкт домену повинен бути постійним неосвіченим, та багато інших правил із подібних книг .

Другі об'єкти домену в Active Record мають тенденцію 1-до-1 з базою даних, що може вважатися обмеженням у деяких системах (переважно n-ярусів).

Це просто абстрактні речі, я не бачив рубіну на рейках реальної реалізації цієї моделі.

Проблема, яку я бачу з Active Records, полягає в тому, що це завжди лише одна таблиця. Це нормально, якщо ви дійсно працюєте лише з цією однією таблицею, але коли ви працюєте з даними в більшості випадків, ви десь приєднаєтесь.

Так, приєднання зазвичай гірше, ніж взагалі не приєднується, коли мова йде про продуктивність, але приєднання зазвичай краще, ніж "підроблене" з'єднання , спочатку прочитавши всю таблицю А, а потім використовуючи отриману інформацію для читання та фільтрації таблиці Б.

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

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

Хоча всі інші коментарі щодо оптимізації SQL, безумовно, справедливі, моя головна скарга на схему активних записів полягає в тому, що вона зазвичай призводить до невідповідності імпедансу . Мені подобається підтримувати чистий і належним чином інкапсульований мій домен, що, як правило, активний зразок запису руйнує усі сподівання.

Спробуйте зробити багато-багато поліморфних стосунків. Не так просто. Особливо, коли ви не використовуєте STI.