Приложение C# - следует ли использовать хранимые процедуры или ADO.NET с методами программирования на C#?

Что ж, хранимые процессы могут быть дополнительным уровнем абстракции или набором функций / методов, если вы смотрите на базу данных как на объект или службу. Это может быть полезно, поскольку вы можете скрыть базовые детали реализации и изменить их, когда это необходимо, не нарушая работу приложения (пока вы оставляете только интерфейс, например, сохраненные параметры процедуры). Кроме того, если вы можете скрыть детали своей таблицы за набором сохраненных процедур, независимо от того, как кто-то получит доступ к вашей базе данных, они смогут взаимодействовать с ней только с помощью методов, которые вы разработали и написали для нее -> там меньше риск того, что кто-то запустит Excel и взломает вашу базу данных.

С другой стороны, Stored Proc требует обширных знаний T-SQL, и вы будете распределять свой бизнес и логику приложения по двум наборам кодовых баз, что может быть недостатком. Все, что вы можете делать в хранимой процедуре, также можно сделать в ADO.NET с помощью прямых операторов SQL, и это уже не медленнее.

Еще одним плюсом для хранимых процедур является тот факт, что если в вашей процедуре что-то не так, вы можете исправить это, просто развернув процедуру с исправлением - вам не нужно трогать свое приложение C#. Это может быть большим плюсом в «размещенной» среде, если вы получаете только 3 релиза в год - тогда применение исправления посредством исправления хранимой процедуры может быть вашей спасительной операцией! :-)

В общем: есть много плюсов и минусов за или против хранимых процессов; Я бы посоветовал, если вы чувствуете себя комфортно при написании T-SQL, почему бы не попробовать и не посмотреть, как он работает для вас. Если он кажется громоздким, слишком негибким или требует слишком много работы в долгосрочной перспективе, вы всегда можете вернуться к использованию прямого SQL в своем приложении C#.

Только мои 0,02 доллара. Марк

Что ж, в любом случае вы собираетесь использовать ADO.NET ... похоже, вы имеете в виду хранимые процедуры и текст команды. К сожалению, у обоих есть преимущества, так что это непростой вопрос, однако, если вы смотрите на такие инструменты, как LINQ, у command-text больше преимуществ, поскольку он может быть более "компонуемым" (т. Е. Вызывающий может добавить Skip / Take / Where / OrderBy и повлиять на общий запрос).

Другой вариант, который сочетает в себе преимущества обоих, - это функции с табличным значением (через UDF) - они также имеют преимущество более сильных метаданных (сложно точно запросить схему хранимой процедуры).

Любой подход должен быть безопасным для инъекций, если вы правильно используете параметры.

Позвольте мне перефразировать это: если вы извлекаете данные, изменяете их в коде, а затем наличие SP обновляет БД новыми значениями, или вы просто вызываете SP как «функцию» .
Я хочу подчеркнуть, что даже если вы выполняете манипуляции с данными в коде, вы все равно должны иметь доступ только к SP в базе данных.

Если вы это сделаете или более сложные SP будут обрабатывать данные, это будет зависеть от нескольких факторов:

• ваш уровень комфорта со сложным SQL (в отличие от C#)
• сколько данных вам нужно вытащить и изменить - могут быть аспекты производительности (вытаскивать все эти данные в код стоит)
• подключенная к предыдущей, ваша архитектура может вступить в игру - например, вы обращаетесь к локальному серверу БД или удаленному
• Какие манипуляции нужно делать, они могут быть настолько сложными, что не захочется замутить свой sql
• Какую бизнес-логику нужно применять, от чего зависят данные и т. д.

Это действительно сводится к вызову суждения, пути верно нет (хотя есть много способов неправильный ...). Хотя важно оставаться последовательным, вполне допустимо иметь в вашей системе различные типы доступа к БД, если это оправдано контекстом / потребностью. Я бы сказал, выбирайте то, что вам удобнее всего, и придерживайтесь этого - пока у вас не будет причины сделать это по-другому. Нет причин относиться к этому категорично ...

Я бы рекомендовал следовать тому или иному соглашению (либо используйте код SQL в виде строк в своих классах, либо используйте хранимые процедуры). По этому поводу ведется бесчисленное количество споров, но на самом деле нет никаких важных причин для выбора того или другого.

Два момента, которые еще не были рассмотрены:

SProcs можно поместить в схему и олицетворять другую схему. Это означает, что вы можете заблокировать доступ к базе данных и предоставить пользователям разрешения ТОЛЬКО на выполнение ваших SProcs, а не на выбор обновлений и т. д., Что является очень хорошим бонусом безопасности.

Во-вторых, sproc может быть ЗНАЧИТЕЛЬНО быстрее в зависимости от того, какие операции вы выполняете. Если вы ограничены сетевым вводом-выводом и можете выполнять заданные операции с вашими данными, делая это в одной хранимой процедуре, вместо того, чтобы выполнять выборку ВСЕГО набора данных, обрабатывая его, то передача изменения даст вам хорошее увеличение скорости.

То же самое и с транзакциями: если вам нужно выполнять операции последовательно (т. Е. Изменять значение сразу в двух таблицах, что требует некоторой логики), тогда вам нужно будет удерживать транзакцию на время, необходимое для вычисления значения и передачи обратно в два SQL-запроса, тогда как хранимая процедура может сделать это за одну процедуру.