Найкраща практика запиту даних із MS SQL Server у C #?

Який найкращий спосіб запиту даних із MS SQL Server у C #?

Я знаю, що не правильно застосовувати SQL-запит у коді.

Це найкращий спосіб створити збережену процедуру і викликати її з C # з параметрами?

using (var conn = new SqlConnection(connStr))
using (var command = new SqlCommand("StoredProc", conn) { CommandType = CommandType.StoredProcedure }) {
   conn.Open();
   command.ExecuteNonQuery();
   conn.Close();
}

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

Більш сучасний спосіб взаємодії з базами даних SQL Server з C # (або будь-якої мови .NET) - це використання Entity Framework. Перевага Entity Framework полягає в тому, що він забезпечує більш високий рівень абстракції.

Цитувати від Microsoft ( https://msdn.microsoft.com/en-us/data/jj590134 ):

Система ADO.NET Entity Framework дозволяє розробникам створювати програми доступу до даних, програмуючи їх на концептуальній моделі програми, а не програмуючи безпосередньо на реляційній схемі зберігання даних. Мета - зменшити кількість коду та обслуговування, необхідне для програм, орієнтованих на дані. Програми Entity Framework надають такі переваги:

• Програми можуть працювати в контексті концептуальної моделі, орієнтованої на додатки, включаючи типи з успадкуванням, складними членами та відносинами.
• Програми звільняються від твердо кодованих залежностей певного механізму передачі даних або схеми зберігання.
• Відображення між концептуальною моделлю та специфічною для зберігання схемою може змінюватися без зміни коду програми.
• Розробники можуть працювати з послідовною моделлю об'єктної програми, яку можна відобразити на різних схемах зберігання, можливо, реалізованих у різних системах управління базами даних.
• Кілька концептуальних моделей можуть бути відображені в одній схемі зберігання.
• Підтримка мовних інтегрованих запитів (LINQ) забезпечує перевірку синтаксису часу компіляції для запитів проти концептуальної моделі.

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

"Класичний" підхід до розробки за допомогою SQL Server полягає в тому, щоб логіка програми знаходилася в збережених процедурах і програмах, що мають лише права безпеки на виконання збережених процедур, а не на оновлення таблиць безпосередньо. Концепція тут полягає в тому, що збережені процедури - це рівень бізнес-логіки для додатків. Незважаючи на те, що теорія є надійною, вона, як правило, не виходить з різних причин, замінюючись реалізацією бізнес-логіки мовою програмування на зразок C # або VB. Хороші програми все ще реалізуються з багаторівневим підходом, включаючи розділення проблем тощо, але, швидше за все, вони дотримуються такої моделі, як MVC.

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

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

Насправді основне твердження є дискусійним - є компроміси як у випадку між наявністю SQL у коді, так і кодом у базі даних (саме там ви прямуєте із збереженими процедурами).

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

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

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

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

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

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

• Як вказує @Bill, ви завжди повинні параметризувати запити. Створення рядків - це простий вектор для ін'єкцій SQL, а також усілякі труднощі для відстеження помилок. Набагато розумніші люди придумали, як настроїти та врятувати sql, тому вам не потрібно розбиратись самі.

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

Інша практика, за яку я наполегливо стверджую, полягає в тому, що ви повинні переконатися, що ви сконцентрували код доступу до даних якомога менше місць. Ми не дозволяємо переднім веб-програмам прямо посилатися на System.Data.SqlClient, щоб допомогти виконувати цей застереження.