Спільне використання збережених процедур у кількох програмах

Команда A має корпоративну програму, яка використовує ADO.NET для доступу до даних, яка виконує збережені процедури. Доступ до даних інкапсульований у власному проекті (назвемо його DAL.dll )

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

Один із способів зробити це, щоб проект команди B додав посилання на DAL.dll

Я хотів би знати, чи є якісь чистіші шляхи вирішення проблеми. Ми готові замінити блок даних MS Team Team на використання іншої технології (Entity Framework?), Якщо це необхідно.

2
"Принаймні, ми хотіли б, щоб програма кинула помилку компіляції, щоб процес збирання попереджав нас про внесені зміни.", Що ще ви очікуєте від вашого процесу складання?
додано Автор Karl Anderson, джерело

7 Відповіді

Серед інших відповідей, я настійно рекомендую перенести ці збережені процедури до керування джерелами, у Проект баз даних . Тоді ви зможете скористатися функціями системи керування джерелами для виконання кількох дій:

  1. Заблокуйте деякий код, щоб його не можна змінити
  2. Дати вам сповіщення, якщо код змінено
  3. Попереджати, якщо збережені процедури змінюються таким чином, щоб запобігти їх виклику
  4. Розміщуйте збережені процедури, щоб кожна команда могла мати свою власну версію зміненого коду, зберігаючи при цьому незмінені збережені процедури. Вам, звичайно, потрібно буде розділити різні версії в базі даних.
3
додано
Контроль джерела +1 - це велике знання того, що відбувається
додано Автор eglasius, джерело

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

Спільний рівень доступу до даних може працювати, але концептуально ви просто змінюєте реалізацію залежності від деякого коду, який DBA написав до коду, який написав програміст .NET. Так, ви можете використовувати тести інтеграції для досягнення кращої можливості перевірки, але той самий випадок може бути зроблений для SQL з інструментами, такими як SQL-тест Red Gate. Я б ухилявся від такого підходу, якщо дві програми вже відчувають певний біль від спільного використання SP. Це є свідченням того, що залежність просто повинна бути ліквідована.

Якби це було до мене, я б просто зробив нову схему для програми B команди. Докладніше про схеми в SQL Server читайте тут: Опис схеми MSDN 2008 R2 . Ви можете думати про них як про просторі імен для SQL Server, але з деякими додатковими дзвінками і свистями, як дозвіл і контроль доступу. Поділ різних програм на окремі схеми на одній і тій самій спільній базі даних, ймовірно, зробить найбільш гнучкою реалізацію в довгостроковій перспективі.

2
додано

Незв'язане додаток, що повторно використовує збережені процедури в програмі підприємства

If these two application are really unrelated why are those sharing procedures or even the same database. I know this is a long read, but I recommend you to read this: A Better Path to Enterprise Architectures

Концепція розподілу розділів стосується обмеженого контексту в проекті, керованому доменом

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

     

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

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

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

1
додано

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

Кращий спосіб обміну даними/функціональними можливостями між двома різними додатками - через сервіс або API, тому команда, яка володіє функціональністю, відповідає за її підтримку.

Крім того, мати хороший зв'язок між обома командами дуже рекомендую.

1
додано

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

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

0
додано
Щоб розширити цю проблему, я запропонував би вам реалізувати шаблон сховища, отже, якщо хтось змінить реалізацію в класах DAL, визначених у інтерфейсі, ви отримаєте помилку збирання. Існує, звичайно, можливість того, щоб хтось забув помістити підпис DAL-методу в інтерфейсі і обійти цю перевірку без реалізації, але компілятор все одно ловить невідповідні аргументи/параметри.
додано Автор Karl Anderson, джерело

"Я хотів би знати, чи є якісь чистіші способи вирішення проблеми".

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

Один розумний механізм для цього в середовищі .NET - це використання WebAPI .

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

0
додано

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

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

0
додано
var chat = new Chat();
var chat = new Chat();
642 учасників

Обсуждение вопросов по C# / .NET / .NET Core / .NET Standard / Azure Сообщества-организаторы: — @itkpi — @dncuug