Чи слід вводити ділову логіку у Збережений порядок чи ні?

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

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

Будь-які пропозиції ...?

Я б застосував прагматичний підхід - історично головна «користь» від збереження бізнес-логіки у збережених документах є з міркувань продуктивності (2.5-ярусна архітектура), тоді як розділення ділової логіки на рівень BLL (3 / N-рівень), як правило, більш чистий від перспектива технічного обслуговування та простіша перевірка (макет / заглушка доступу до даних).

Однак, враховуючи, що з підтримкою LINQ .NET ORMS, такими як LINQ2SQL, EF та NHibernate, тепер створюються параметризовані запити SQL, де плани запитів можна кешувати, уникати для ін'єкції SQL тощо. більш переконливим, ніж будь-коли, і більшості SPROC (особливо орієнтованих на запити) можна взагалі уникнути. Шаблони репозиторіїв у .NET зазвичай піддають IQueryable / accept параметрів дерева Expression, що забезпечує безпечний тип, але гнучкий доступ до ваших таблиць. (Особисто в архітектурах типу SOA я б не виставляв IQueryable за межами BLL, тобто ваші рівні обслуговування та презентації повинні працювати з чітко визначеним набором методів. Причина полягає в тому, що в іншому випадку ви ніколи не можете повністю протестувати свою систему, і ви виграли '

Однак у системі пристойного розміру завжди буде кілька винятків, коли дійсно інтенсивний фрагмент коду, можливо, все ж повинен бути записаний як Stored Proc з міркувань продуктивності. У цих випадках я б утримував SPROC і викривав би SPROC через ORM, але все-таки викривав би функцію як метод проходження у вашому BLL.

Будучи розробником Java, моїм уподобанням було вкласти ділову логіку в BLL (приємний та простий контроль джерел, знайомство тощо тощо тощо).

Однак після роботи на великому підприємстві з великою кількістю розповсюджених додатків з використанням різних технологій (C #, Java, Pick (не запитувати)) стала очевидною одна істотна перевага використання збережених процедур:

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

У нашій команді тут діє м'яке правило. Іноді краще вирішити Business Logic в T-SQL, іноді це простіше зробити в c # (Business Layer).

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

Для обох (на мою думку) є переваги та недоліки:

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

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

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

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

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

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

Логіка повинна бути в BLL завжди, оскільки:

• Це можна правильно перевірити
• Коли SQL 20XX застаріває і вам потрібно перейти на останню версію, вам не доведеться переписувати код.
• Люди не спокушаються вносити зміни на ходу (що, здається, висувається як аргумент ЗА СП)
• На мій досвід, SP - це найбільша помилка розробника, особливо після декількох поколінь обслуговування / змін.

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

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

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

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

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