Чи є написання власного шару доступу до даних / картографічних даних «хорошою» ідеєю?

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

У нас є застаріле додаток (ASP.NET + SQL Server), де рівень даних та бізнес-рівень, на жаль, пюре разом. Система не є особливо складною з точки зору доступу до даних. Він читає дані з великої групи (35-40) взаємопов’язаних таблиць, маніпулює ними в пам'яті та зберігає їх назад до деяких інших таблиць у форматі зведення. Зараз ми маємо можливість здійснити деякий рефакторинг і дивимось на кандидатські технології, які можна використовувати для окремої та належної структури нашого доступу до даних.

Яку б технологію ми не вирішили, ми хотіли б:

• в нашій доменній моделі є об'єкти POCO, які є ігноруючим наполегливістю
• мати шар абстракції, який дозволяє нам тестувати об'єкти нашої моделі домену на макетному базовому джерелі даних

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

Особисто я наполягаю на використанні EF спільно з генератором тестових репозиторіїв ADO.NET Unit / Generator сущностей POCO . Він задовольняє всі наші вимоги, може бути легко вбудований в шаблон Repo / UnitOfWork, і наша Структура БД досить зріла (вже зазнала рефактор), тому ми не будемо щодня вносити зміни в модель.

Однак інші в групі пропонують архітектуру / згортання власного DAL повністю з нуля. (Спеціальні DataMappers, DataContexts, сховище, інтерфейси скрізь, надмірне введення залежностей для створення конкретних об'єктів, користувацький LINQ-базовий переклад запитів, користувальницькі керування реалізаціями, користувацькі FetchPlan реалізації ...) список продовжується і буде відвертим - це страйки. мене як божевілля.

Деякі аргументи, про які йдеться, - це "принаймні, ми будемо контролювати власний код" або "О, я використовував L2S / EF у попередньому проекті, і це було не що інше, як головний біль". (Хоча я раніше використовував як у виробництві, так і виявив, що будь-які проблеми мало і далеко між ними, і дуже керовані)

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

Обидва аргументи проти існуючих ORM недійсні:

"Ну принаймні ми будемо контролювати власний код"

Чому б не написати свою мову? Ваша власна рамка? Ваша власна операційна система? І щоб бути впевненим, що ви все контролюєте, це також гарна ідея створити власне обладнання.

"О, я використовував L2S / EF в попередньому проекті, і це було не що інше, як головний біль"

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

Отже, чи потрібно писати власну ORM?

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

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

Звичайно, ніщо не забороняє вам писати власну ОРМ просто з цікавості, щоб дізнатися щось. Але не варто робити це на комерційному проекті.

Дивіться також пункти 2 - 3 моєї відповіді на питання Повторне винахід колеса і НЕ шкодуючи про це. Видно, що різні причини винаходити колесо тут не стосуються.

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

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

Суть полягає в тому, що це може мати сенс, лише за правильних умов. Ці умови, як правило, включають:

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

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

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

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

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

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

Редагувати:

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

Редагування 2: (на кшталт пропозиції @ CmdKey): Хоча прямо не зазначено, я припускаю, що оцінка непрямо включатиме оцінку ризику. Зокрема, оцінка часу зазвичай повинна включати номери в стилі PERT:

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

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

Зазвичай ніколи не годиться винаходити колесо, і це зазвичай є вказівкою на технічне незнання ("я нічого іншого не знаю і не хочу вчитися") або зарозумілість ("X дурний, я можу написати власний інструмент за два тижні! "); Є зрілі інструменти, які можуть зробити речі набагато краще, ніж те, що середній розробник може зламати разом за кілька тижнів.

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

Я був над проектом, який відхилив існуючі інструменти Java ORM, щоб написати свої власні, через деяку "критичну" особливість, якої не було в режимі hibernate. Це була багатомільйонна помилка, а вартість зростає щодня. Вони все ще не мають повної підтримки для об'єктних відносин. Отже, крім всього часу, витраченого на створення та підтримку фреймворку, вони витрачають години на написання коду, який можна було б записати за лічені хвилини за допомогою режиму сплячки, або в багатьох випадках взагалі не потрібно було б писати.

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

Код, який ви повинні написати - це код, який ви повинні підтримувати. Час, витрачений на підтримку коду ORM, - це час, не витрачений на підтримку програми. Якщо ОРМ не дає певної стратегічної переваги, то це не те, що збирається заробляти гроші для бізнесу, тому це чисті накладні витрати. Чи скоріше ваша компанія витратить гроші на накладні витрати або на підвищення грошового продукту? Якщо це для внутрішнього додатка, це може бути проблемою, але ви все ще збільшуєте кількість коду, який потрібно буде написати, протестувати та задокументувати.

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

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

Нові продукти EF виглядають досить добре, але якщо ви хочете більшого контролю - я б поглядав на мікро ORM / s на кшталт: Drapper http://code.google.com/p/dapper-dot-net/ або PetaPOCO http : //www.toptensoftware.com/petapoco/

Ви також можете змішувати та поєднувати - використовуйте EF для основної маси та Drapper для тонкої настройки.

У будь-якому випадку це лише мій 2с;)