Навіщо нам потрібні об'єкти сутності? [зачинено]

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

Я не переконаний, що об'єкти сутності повинні існувати.

Під об'єктами сутності я маю на увазі типові речі, які ми схильні будувати для наших додатків, наприклад "Особа", "Рахунок", "Замовлення" тощо.

Моя нинішня філософія дизайну така:

• Весь доступ до бази даних повинен здійснюватися через збережені процедури.
• Кожен раз, коли вам потрібні дані, викличте збережену процедуру та повторіть її через SqlDataReader або рядки в таблиці даних

(Примітка. Я також створив корпоративні додатки з Java EE; java люди, будь ласка, замініть еквівалент моїми .NET прикладами)

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

Я не будую іграшки. Я говорю про великі, великі за обсягом транзакційні програми, розгорнуті на декількох машинах. Веб-додатки, сервіси Windows, веб-сервіси, взаємодія b2b, ви її називаєте.

Я використовував АБО Mappers. Я написав декілька. Я використав стек Java EE, CSLA та кілька інших еквівалентів. Я не тільки використовував їх, але активно розробляв і підтримував ці програми у виробничих умовах.

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

Розглянемо цей простий приклад: ви отримуєте виклик підтримки щодо певної сторінки у вашій програмі, яка не працює належним чином, можливо, одне з полів не зберігається так, як має бути. З моєю моделлю розробник, призначений знайти проблему, відкриває рівно 3 файли . ASPX, ASPX.CS і файл SQL із збереженою процедурою. Проблема, яка може бути відсутнім параметром для виклику збереженої процедури, займає кілька хвилин. Але з будь-якою моделлю сутності ви незмінно запустите налагоджувач, почнете переглядати код і, можливо, у візуальній студії відкриєте 15-20 файлів. На той момент, коли ви спустилися до нижньої частини стека, ви забули, з чого почали. Ми можемо одночасно тримати стільки речей у голові. Програмне забезпечення неймовірно складне без додавання зайвих шарів.

Складність розробки та усунення несправностей - це лише одна зі сторін моєї суті.

Тепер поговоримо про масштабованість.

Чи усвідомлюють розробники, що кожен раз, коли вони пишуть або змінюють будь-який код, який взаємодіє з базою даних, їм потрібно робити точний аналіз точного впливу на базу даних? І не лише копія розробки, я маю на увазі міміку виробництва, тож ви можете бачити, що додатковий стовпець, який ви зараз потребуєте для вашого об'єкта, просто визнав недійсним поточний план запитів, а звіт, який працює за 1 секунду, тепер займе 2 хвилини, просто оскільки ви додали один стовпець до списку вибору? І виходить, що індекс, який вам зараз потрібен, настільки великий, що DBA буде потрібно змінювати фізичний макет ваших файлів?

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

Я не завзятий. Я можу переконатися, що я помиляюся, і, можливо, я є, оскільки є такий сильний поштовх у напрямку до Linq до Sql, ADO.NET EF, Hibernate, Java EE тощо. Будь ласка, продумайте ваші відповіді, якщо я щось пропускаю дуже хочу знати, що це таке, і чому я повинен змінити своє мислення.

[Редагувати]

Схоже, що це запитання знову стає активним, тому тепер, коли у нас є нова функція коментарів, я прокоментував декілька відповідей. Дякую за відповіді, я думаю, що це здорова дискусія.

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

Я маю викласти тут зверху у відповідь на кілька подібних відповідей: ортогональність та роз'єднаність проблем часто наводяться як причини перейти до сутності / ОРМ. Збережені процедури, на мене, є найкращим прикладом розділення проблем, які я можу придумати. Якщо ви забороните будь-який інший доступ до бази даних, за винятком збережених процедур, ви можете теоретично переробити всю вашу модель даних і не порушити жодного коду, якщо ви підтримували входи та виходи збережених процедур. Вони є прекрасним прикладом програмування за контрактом (до тих пір, поки ви уникаєте "select *" і документуєте набори результатів).

Запитайте у когось, хто довгий час працював у цій галузі та працював із довговічними додатками: скільки прикладних програм та шарів користувальницького інтерфейсу прийшло та відійшло, поки база даних жила? Наскільки важко налаштувати та рефакторировать базу даних, коли є 4 або 5 різних стійких шарів, що генерують SQL для отримання даних? Ви нічого не можете змінити! ORM або будь-який код, що створює SQL, блокує вашу базу даних в камені .

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

Отже, я б сказав, що відповіді однозначного розміру немає. Розробникам потрібно пам’ятати, що іноді намагання бути занадто OO може спричинити більше проблем, ніж вирішує.

Теорія говорить, що вкрай згуртовані, нещільно пов'язані реалізації - це шлях вперед.

Тож я припускаю, що ви ставите під сумнів такий підхід, а саме розділяєте проблеми.

Чи повинен мій файл aspx.cs взаємодіяти з базою даних, викликаючи паросток та розуміти IDataReader?

У командному середовищі, особливо там, де у вас менше технічних людей, які займаються частиною програми aspx, мені не потрібно, щоб ці люди могли "торкатися" до цього матеріалу.

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

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

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

Хоча цікава думка, хоча він відчуває себе за крок від SQL в aspx, який від моїх поганих старих неструктурованих днів asp, наповнює мене страхом.

Одна з причин - відокремлення вашої доменної моделі від вашої моделі бази даних.

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

Для мене це зводиться до того, що я не хочу, щоб моя програма стосувалася того, як зберігаються дані. Я, мабуть, отримаю похизуватися, сказавши це ... але ваша програма - це не ваші дані, дані - артефакт програми. Я хочу, щоб моє додаток було продумане з точки зору клієнтів, замовлень та предметів, а не таких технологій, як DataSets, DataTables та DataRows ... адже хто знає, як довго вони будуть існувати.

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

Я схильний зарезервувати відростки для звітності, оскільки запити, як правило, стають трохи неприємнішими, ніж загальний доступ до даних додатків.

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

Еріку, ти мертвий. Для будь-якого дійсно масштабованого / легко підтримуваного / надійного додатку єдиною реальною відповіддю є відмовитися від усього сміття та дотримуватися основ.

Я дотримувався подібної траєкторії своєї кар’єри і дійшов таких же висновків. Звичайно, нас вважають єретиками і дивляться на смішно. Але моя робота працює і працює добре.

На кожен рядок коду слід дивитися з підозрою.

Я хотів би відповісти на прикладі, подібному до запропонованого вами.

У моїй компанії мені довелося створити простий розділ CRUD для продуктів, я будую всі свої організації та окремий DAL. Пізніше інший розробник повинен був змінити відповідну таблицю, і він навіть перейменував кілька полів. Єдиний файл, який мені довелося змінити, щоб оновити форму, був DAL для цієї таблиці.

Що (на мою думку) суб'єкти сприяють проекту, це:

Ортогональність: Зміни в одному шарі можуть не впливати на інші шари (поза курсом, якщо ви внесете величезні зміни в базу даних, вона прошиватиме всі шари, але більшість невеликих змін не призведе).

Заповітність: Ви можете перевірити свою логіку, торкнувшись вашої бази даних. Це збільшує продуктивність ваших тестів (дозволяє запускати їх частіше).

Розділення проблем: У великому продукті ви можете призначити базу даних для DBA, і він може оптимізувати її. Призначте Модель бізнес-експерту, який має знання, необхідні для його розробки. Призначте індивідуальні форми розробникам, які мають більш досвідчені веб-форми тощо.

Нарешті, я хотів би додати, що більшість картографістів ORM підтримують збережені процедури, оскільки саме це ви використовуєте.

Ура.

Я думаю, що ви можете "кусати більше, ніж можете жувати" на цю тему. Тед Ньюард не був легковажним, коли назвав його " В'єтнамом комп'ютерних наук ".

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

Безумовно, нормально мати відкрите невдоволення та дискусії щодо суперечливої ​​теми, це саме ця справа робилася стільки разів, що обидві "сторони" погодилися не погодитися і просто почали писати програмне забезпечення.

Якщо ви хочете трохи прочитати обидві сторони, перегляньте статті в блозі Теда, Айенде Рахейн, Джиммі Нілсон, Скотт Беллвер, Alt.Net, Стівен Форте, Ерік Еванс тощо.

@Dan, вибач, це не те, що я шукаю. Я знаю теорію. Ваше твердження "дуже погана ідея" не підкріплене реальним прикладом. Ми намагаємось розробляти програмне забезпечення за менший час, з меншою кількістю людей, з меншою кількістю помилок, і хочемо можливість легко вносити зміни. На мій досвід, ваша багатошарова модель є негативною у всіх перерахованих вище категоріях. Особливо що стосується того, щоб зробити модель даних останньою справою. Фізична модель даних повинна бути важливою увагою з першого дня.

Я вважав ваше запитання справді цікавим.
Зазвичай мені потрібні об'єкти, щоб об'єднати бізнес-логіку програми. Було б дуже складно і неадекватно просунути цю логіку в рівень даних.
Що б ви зробили, щоб уникнути цих об'єктів? Яке рішення ви маєте на увазі?

Об'єкти сутності можуть полегшити кешування на рівні додатків. Удачі в кешування даних.

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

Є цінність у багатих моделях домену. Саме про це і полягає дизайн, керований доменом . Я особисто вважаю, що ОО - це спосіб перемогти складність. Це означає не тільки технічну складність (наприклад, доступ до даних, прив'язування інтерфейсу, безпеку ...), але і складність у сфері бізнесу !

Якщо ми можемо застосувати методи OO для аналізу, моделювання, проектування та реалізації наших бізнес-проблем, це величезна перевага для ремонтопридатності та розширюваності нетривіальних додатків!

Існують відмінності між вашими сутностями та вашими таблицями. Суб'єкти повинні представляти вашу модель, таблиці просто представляють аспект даних вашої моделі!

Це правда , що дані живуть довше , ніж додатки, але вважають цю цитату з Девіда Laribee : Моделі назавжди ... дані щасливий побічний ефект.

Ще кілька посилань на цю тему:

• Чому сетери та геттери - це зло

• Повернення чистого ОО

• POJO vs. NOJO

• Супермоделі, частина 2

• TDD, Макети та дизайн

Дійсно цікаве питання. Чесно кажучи, я не можу довести, чому сутності хороші. Але я можу поділитися своєю думкою, чому вони мені подобаються. Код, як

void exportOrder(Order order, String fileName){...};

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

Реалізація цього методу здійснюватиметься на основі абстракції, а не на основі того, як саме він представлений у БД. Більшість таких операцій, які я реалізував, дійсно не залежать від того, як зберігаються ці дані. Я розумію, що для деяких операцій потрібна зв'язок зі структурою БД для ефективності та масштабованості, просто, на мій досвід, їх не так вже й багато. На моєму досвіді дуже часто достатньо знати, що Person має .getFirstName (), що повертає String, і .getAddress (), що повертає адресу, та адресу має .getZipCode () тощо, - і не важливо, які таблиці викличуються для зберігання цих даних .

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

Масштабування тут є цікавим моментом - більшість веб-сайтів, які потребують величезної масштабованості (наприклад, facebook, livejournal, flickr), як правило, використовують DB-аскетичний підхід, коли БД використовується якомога рідше, а проблеми масштабованості вирішуються кешуванням, особливо використанням оперативної пам'яті. На сайті http://highscalability.com/ є цікаві статті.

Є й інші вагомі причини для об'єктів сутності, окрім абстрагування та нещільного з’єднання. Одна з речей, яка мені найбільше подобається, - це сильне введення тексту, яке неможливо отримати за допомогою DataReader або DataTable. Ще одна причина полягає в тому, що, коли це зроблено добре, належні класи сутностей можуть зробити код більш корисним, використовуючи конструкції першого класу для конкретних доменних термінів, які кожен, хто дивиться на код, швидше за все зрозуміє, а не купу рядків із назви полів, що використовуються для індексації DataRow. Збережені процедури дійсно є ортогональними для використання ORM, оскільки багато карток карток дають вам можливість відображати проростки.

Я б не вважав sprocs + читачів даних заміною хорошого ORM. Зі збереженими процедурами ви все ще обмежені підписом типу процедури і щільно пов'язаним з цим підписом процедури, який використовує іншу систему типу, ніж код виклику. Збережені процедури можуть бути змінені, щоб змінити додаткові параметри та зміни схеми. Альтернативою збереженим процедурам у випадку, коли схема може підлягати змінам, є використання представлень - ви можете зіставляти об’єкти на представлення даних, а потім перемальовувати подання на основні таблиці, коли ви їх змінюєте.

Я можу зрозуміти вашу неприязнь до ORM, якщо ваш досвід в основному складається з Java EE та CSLA. Можливо, ви хочете ознайомитись з LINQ до SQL, що є дуже легким каркасом і, головним чином, зіставленням один на один із таблицями баз даних, але зазвичай потрібно лише незначне розширення, щоб вони були повномасштабними бізнес-об'єктами. LINQ в SQL також може відображати об'єкти введення та виводу на параметри та результати збережених процедур.

Перевага ADO.NET Entity має додаткову перевагу в тому, що таблиці ваших баз даних можуть розглядатися як класи об'єктів, що успадковують один одного, або як стовпці з декількох таблиць, об’єднаних в одне ціле. Якщо вам потрібно змінити схему, ви можете змінити відображення від концептуальної моделі до схеми зберігання без зміни фактичного коду програми. І знову, тут можна використовувати збережені процедури.

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

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

Що робити, якщо вам потрібно масштабувати додаток, балансуючи навантаження на більш ніж один веб-сервер? Ви можете встановити повний додаток на всіх веб-серверах, але кращим рішенням є розмовляти з веб-серверами із сервером додатків.

Але якщо немає об’єктів сутності, про них не доведеться дуже багато говорити.

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

Це економить час, коли йдеться про його утримання.

Розділяючи логіку програми від логіки презентації та доступу до даних та передаючи DTO між ними, ви їх роз’єднуєте. Дозволити їм змінюватися самостійно.

Ви можете знайти цей пост на comp.object цікавого.

Я не претендую на згоду чи незгоду, але це цікаво і (я думаю), що стосується цієї теми.

Питання: Як ви обробляєте відключені програми, якщо вся ваша бізнес-логіка потрапляє в базу даних?

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

Для збереження шару домену в збережених процедурах в базі даних вам потрібно дотримуватися єдиного типу додатків, який потребує постійного огляду баз даних.

Для певного класу середовищ це нормально, але це, звичайно, не охоплює весь спектр програм Enterprise .

@jdecuyper, одна із максим, яку я повторюю собі часто, - це "якщо ваша бізнес-логіка відсутня у вашій базі даних, це лише рекомендація". Думаю, Пол Нільсон сказав про це в одній зі своїх книг. Прикладні шари та інтерфейс користувальницького інтерфейсу надходять та йдуть, але дані зазвичай живуть дуже довго.

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

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

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

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

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

Однак, як уже зазначалося вище, "ідеального дизайну" немає, інструмент повинен відповідати роботі. Але використання суб’єктів господарювання справді може допомогти в обслуговуванні та продуктивності, оскільки ви знаєте, куди звернутися, щоб змінити бізнес-логіку, а об’єкти можуть інтуїтивно зрозуміти моделювання реальних понять.

Еріку,

Ніхто не заважає тобі вибирати рамку / підхід, який ти хотів би. Якщо ви збираєтесь пройти шлях "керованими даними / збереженими даними процедурами", тоді, будь-ласка, ідіть до цього! Особливо, якщо це дійсно, справді допомагає вам доставляти свої додатки вчасно та вчасно.

Застереження, що є вашим запитанням, ВСІ ваші ділові правила повинні дотримуватися збережених процедур, і ваша заява - це не що інше, як тонкий клієнт.

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

Єдине справжнє правило тут - слово послідовність . Ніхто не заважає тобі переходити до БД. Ніхто не заважає вам робити структуровані (так звані, функціональні / процедурні) програми для старої школи. Чорт, ніхто не перешкоджає виконувати код у стилі COBOL. Але заявка повинна бути дуже, дуже послідовною, коли йде по цьому шляху, якщо вона бажає досягти будь-якого ступеня успіху.

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

Але що робити, якщо у вас була база даних зі 100 таблицями, які прирівнюються до 4 збережених процедур для кожної таблиці лише для основних операцій CRUD, це 400 збережених процедур, які потрібно підтримувати і не набирати сильного типу, тому вони чутливі до помилок друку і не можуть бути перевірені. . Що станеться, коли ви отримаєте нового CTO, який є євангелістом з відкритим кодом та хоче змінити RDBMS з SQL Server на MySql?

Сьогодні багато програмного забезпечення, незалежно від того, чи застосовують корпоративні програми або продукти SOA та мають певні вимоги до розкриття веб-служб, принаймні програмне забезпечення, яким я є і в якому я був задіяний. Використовуючи свій підхід, ви в кінцевому підсумку відкриєте серіалізовані таблиці даних або DataRows. Тепер це може вважатися прийнятним, якщо Клієнт гарантовано працює .NET і у внутрішній мережі. Але коли Клієнт не відомий, ви повинні прагнути розробити інтуїтивно зрозумілий API, і в більшості випадків ви не хочете виставляти схему повної бази даних. Я, звичайно, не хотів би пояснювати розробнику Java, що таке DataTable і як ним користуватися. Існує також врахування пропускної здатності та розміру корисної навантаження та серіалізованих таблиць даних, набори даних дуже важкі.

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

тільки мої 2 копійки

Я хотів би запропонувати ще один кут до проблеми відстані між ОО та RDB: історія.

Будь-яке програмне забезпечення має модель реальності, яка певною мірою є абстракцією реальності. Жодна комп’ютерна програма не може охопити всі складності реальності, а програми написані просто для вирішення набору проблем із реальності. Тому будь-яка модель програмного забезпечення - це зменшення реальності. Іноді програмна модель змушує реальність зменшувати себе. Як і коли ви хочете, щоб компанія з прокату автомобілів зарезервувала будь-яку машину для вас до тих пір, поки вона синя і має сплави, але оператор не може виконати її, оскільки ваш запит не вміститься в комп'ютер.

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

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

Я здогадуюсь, що ОО повинно відбутися, коли люди виявили, що інші аспекти реальності важче моделювати, ніж бухгалтерський облік (що вже є моделлю). OO стала дуже вдалою ідеєю, але збереження даних про OO порівняно недостатньо розвинене. RDB / Бухгалтерія отримала легкі виграші, але ОО є значно більшим полем (в основному все, що не є бухгалтерським).

Так багато з нас хотіли використовувати OO, але ми все ще хочемо безпечного зберігання наших даних. Що може бути безпечніше, ніж зберігати наші дані так само, як це робить поважана система обліку? Це заманливо перспективи, але всі ми стикаємося з одними і тими ж підводними каменями. Дуже мало хто взяв клопот подумати про наполегливість ОО порівняно з великими зусиллями галузі RDB, яка користувалася традицією та становищем бухгалтерського обліку.

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

Зберігання об'єктів у старих хороших файлах навіть не сприймається серйозно для багатокористувацьких програм, особливо для веб-додатків.

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

Я буду щасливо здивований, коли пропасть назавжди закриється. Я думаю, що рішення знайдеться, коли Oracle запустить щось на кшталт "Oracle Object Instance Base". Щоб дійсно наздогнати, йому доведеться мати заспокійливу назву.

Наразі не так багато часу, але просто вгорі голови ...

Модель сутності дозволяє надати послідовний інтерфейс до бази даних (та інших можливих систем) навіть поза тим, що може зробити інтерфейс збереженої процедури. Використовуючи бізнес-моделі для всіх підприємств, ви можете переконатися, що всі програми впливають на дані послідовно, що ДУЖЕ важливо. Інакше ви закінчитеся з поганими даними, що є просто простим злом.

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

Ось кілька речей, про які слід пам’ятати (IMO), хоча:

1. Створений код SQL поганий (винятки слід). Вибачте, я знаю, що багато людей думають, що це величезна економія часу, але я ніколи не знайшов системи, яка могла б генерувати більш ефективний код, ніж те, що я могла написати, і часто код просто жахливий. Ви також часто отримуєте тону коду SQL, який ніколи не використовується. Виняток тут - дуже прості візерунки, як, можливо, таблиці пошуку. Дуже багато людей захоплюються цим.
2. Субстанції <> Таблиці (або навіть об'єкти логічної моделі даних обов'язково). Модель даних часто має правила даних, які слід застосовувати якомога ближче до бази даних, які можуть включати правила щодо того, як рядки таблиць співвідносяться один з одним або інші подібні правила, занадто складні для декларативного RI. З ними слід оброблятись у збережених процедурах. Якщо всі ваші збережені процедури є простими документами CRUD, ви не можете цього зробити. Крім того, модель CRUD зазвичай створює проблеми з продуктивністю, оскільки вона не зводить до мінімуму поїздки по всій мережі до бази даних. Це часто найбільше вузьке місце у корпоративній програмі.

Іноді ваш додаток та рівень даних не так міцно поєднані. Наприклад, у вас може бути додаток для виставлення рахунків по телефону. Пізніше ви створюєте окрему програму, яка контролює використання телефону, щоб: а) краще рекламувати вас; b) оптимізуйте свій телефонний план.

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

Програми, що мають логіку домену, відокремлену від логіки зберігання даних, пристосовані до будь-якого типу джерел даних (база даних чи іншим способом) або інтерфейсу користувача (веб-або windows (або Linux тощо)).

Ви майже застрягли у вашій базі даних, що непогано, якщо ви працюєте з компанією, яка задоволена існуючою системою баз даних, яку ви використовуєте. Однак, оскільки бази даних розвиваються понаднормово, може з’явитися нова система баз даних, яка є дійсно акуратною та новою, яку хоче використовувати ваша компанія. Що робити, якби вони хотіли перейти до методу доступу до даних веб-служб (наприклад, архітектура, орієнтована на сервіс). Можливо, вам доведеться переносити збережені процедури в усьому місці.

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

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

Я думаю, що ви просто звикли писати конкретний вид заявки та вирішувати певну проблему. Ви ніби атакуєте це з точки зору "першої бази даних". Там багато розробників, де дані зберігаються в БД, але продуктивність не є першочерговим пріоритетом. У багатьох випадках розміщення абстракції над шаром стійкості значно спрощує код, а вартість продуктивності - це не проблема.

Що б ви не робили, це не OOP. Це не помиляється, це просто не OOP, і не має сенсу застосовувати свої рішення до кожної іншої проблеми там.

Цікаве запитання. Пара думок:

1. Як би ви провели тестування, якщо вся ваша бізнес-логіка була у вашій базі даних?
2. Чи не зміни в структурі вашої бази даних, зокрема тих, що стосуються декількох сторінок у вашому додатку, не буде серйозним клопотом, який можна змінити протягом усього додатка?

Гарне питання!

Один із підходів, який мені подобається, - це створити ітератор / генератор-об’єкт, який випромінює екземпляри об'єктів, що відповідають конкретному контексту. Зазвичай цей об’єкт обгортає деякі основні речі доступу до бази даних, але мені не потрібно знати про це при його використанні.

Наприклад,

Об'єкт AnswerIterator генерує об’єкти AnswerIterator.Answer. Під кришкою відбувається ітерація над заявою SQL для отримання всіх відповідей та іншим оператором SQL для отримання всіх пов'язаних коментарів. Але при використанні ітератора я просто використовую об'єкт Answer, який має мінімальні властивості для цього контексту. З невеликим кодом скелета це стає майже банальним.

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

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

Об'єкти в моїх додатках, як правило, відносяться до бази даних, але я вважаю, що використання Linq To Sql, а не відростків значно полегшує написання складних запитів, особливо можливість їх складання за допомогою відкладеного виконання. наприклад, з r в Images.User.Ratings, де і т.д. Це врятує мене, намагаючись опрацювати кілька заяв об'єднання в sql, а пропуск і прийняття для підкачки також спрощує код, а не вбудовувати код row_number & 'over'.

Навіщо зупинятися на об’єктах сутності? Якщо ви не бачите значення об’єктів сутності в додатку на рівні підприємства, просто виконайте доступ до даних чисто функціональною / процедурною мовою та підключіть їх до інтерфейсу користувача. Чому б просто не вирізати весь OO "пух"?