Приветствую.

Недавно начал разбираться с C# и возник вопрос, как правильно INSERT писать? Попинал Google немного и в результате накатал вот чего:

Вкратце суть в том, что надо собрать кучу введенных значений (в данном случае об автомобиле) с разных контролов и вотнуть их [значения] в БД.



Выглядит немного монструозно, на мой взгляд.

Скажем, так написать можно? Будет ли это правильно/безопасно/[...] ?



Это сообщение отредактировал(а) avlzll - 16.12.2009, 01:33

есть такое. К примеру можно и так:


но это не принципиально. так же не обязательно заполнять циклом cmd.Parameters.Add() - для этого есть метод cmd.Parameters.AddRange().



Можно. Только:
во первых, не забывай, что ты работаешь со строками - поэтому твой код со строкой работать не будет.
во вторых - надо будет учитывать типы данных используемой СУБД (для строк использовать кавычки и т.д.)
Очевидно - параметры помогают обойти все эти нюансы.

Вообще на будущее, любое изменение значений БД рекомендуется реализовывать в виде хранимых процедур.

Это неправильно и небезопасно. Насчет неправильно ответил mrbooks, насчет небезопасно - почитай про атаки "SQL Injection".



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


Это сообщение отредактировал(а) advantiss1 - 16.12.2009, 20:32

На самом деле это как с хранением картинок в БД. Можно и ссылкой, и файлом. Хранимая процедура - из этой же оперы. Кому то проще ее использовать, кому то нет. Одни считаю - пусть все делает сервер, другие - клиент.

Цитата из оригинальной статьи


Действительно, если речь идет о "карманном" приложении, разработка которого займет месяц, делать можно как душе пожелается. Но когда речь идет о масштабируемых системах, которые разрабатываются годами - содержание части бизнес логики в БД может в дальнейшем сыграть над разработчиками злую шутку... Сюда же можно отнести и продукты, которые имеют шанс стать массовыми.

advantiss1, 
Статья не плохая. Точка зрения имеет место быть. Но написал её java-разработчик.
Хоть в этом мире и есть много общего, но различия между java и .NET все же есть.



avlzll, 
Выскажу свое мнение, личное.
Я конечно не писал "корпоративные" программы, но несколько программ, которые активно работают с MS SQL server 2005, писал и принимал участие в написании.
Так вот что, я хочу сказать про хранимые процедуры. 
Вместо чистого написания SQL команд в коде приложения практически всегда использовали ХП. Только при работе с БД Access писали SQL команды с параметрами.
Я считаю что, вызов ХП из приложения и передача ей необходимых параметров корааздо удобнее и безопаснее чем использование построителя строки для формирования SQL команды.
Плюс ХП поддерживают выходные параметры + return. Что в свою очередь дает определенные преимущества. Например можно сразу получить ID для сохраненной строки в таблице БД.
А использование return позволяет организовать свою обработку исключений.

В так называемых трех-слойных моделях: слой доступа к данным, слой бизнес логики и слой представления 
никакого смещения бизнес логики приложения из второго слоя в БД не происходит.
В данном случае нижний слой можно реализовать для работы с БД на MS SQL server с использованием ХП, а можно его вообще переписать для работы с XML файлами, в которых будет храниться информация.
Два других слоя приложения об этом даже и знать не будут.
Центральный слой - бизнес логики, сам определяет какие данные ему нужны для работы, что с этими данными делать и что нужно сохранять в БД или другое "хранилице".
Слой представления тоже может быть реализован в двух вариантах: десктопное приложение или веб приложение. Как получаются и обрабатываются данные этому слою по барабану.
Он отвечает только за представление - вывод на экран. Ну и естественно за передачу вниз "действий" пользователя.

Так что все вполне изменяемо и маштабируемо (во завернул).
При переходе с одного хранилища данных на другое нужно переписать только одну dll(слой доступа к данным).
При смене типа приложения переписываем только слой представления.
Ну а при смене бизнес логики переписываем dll слоя бизнес логики.


ЗЫ да забыл упомянуть в дополнение к тому что сказал mrbrooks

 при использовании ХП мы должны передать ей параметры. Так вот при передачи этих самых параметров мы можем легко проверить их на соответствие типу данных и привести к нужному питу.
Плюс выполнить проверку на DBNULL как при получении данных так и при их сохранении в БД. Ну не заполнил пользователь какое-то поле. Знасит мы должны сохранить в БД DBNULL, а при получении данных привести этот DBNULL к простому нулю (0) если это число или дефолтному строковому значению - <не указано>.
Это позволяет избежать исключений при выполнении SQL команд. Особые проблемы вызывают данные типа Datetime. С ХП с ними проблем нет. 

Это сообщение отредактировал(а) thomas - 17.12.2009, 12:04

я сам .NET девелопер, но в данном контесте абсолютно нет разницы какая среда программирования используется. Речь идет о правильном построении приложений с использованием n-звенной архитектуры


если речь идет о переходе с одного SQL движка на другой, то чем больше использовано ХП, нестандартных для SQL функций и других примочек - тем больше займет времени написание библиотеки под другой движок БД(а как всегда всё надо срочно и прямо сейчас)

во. это уже действительно весомый аргумент. бесспорно не во всех СУБД есть ХП (хотя в ведущих они присутствуют). а это дополнительный гемморой.   

advantiss1, 
Приветствую.
Поясню свое высказывание


Под хранилищем данных, я здесь подразумеваю, либо ту или иную базу данных (MS SQL, MySQL, Oracle, ...), либо файловую систему (XML, Sequentiële  файлы, ...) 
Т.е. если по какой то причине клиенту вдруг вздумается  хранить свои данные не в БД, а в виде тех или иных файлов, то просто переписываем DAL на работу с файловой системой.  

А вот по поводу 
могу сказать следующее:
в серьезных конторах при разработке серьезных проектов разработке ВСЕГДА предшествует АНАЛИЗ(да и в не очень серьезных тоже, тут по крайней мере).
Так вот во время анализа и определяется  какой будет система, как и где она будет хранить свои данные, как и какими она их будет обрабатывать, и как она будет взаимодействовать с пользователем.
После правильного АНАЛИЗА вероятность переезда с одной БД на другую маловероятна. Но даже в этом случае вместо переработки всего приложения нужно переписать только один DAL.
К тому же надо учесть и такой момент, что хранимые процедуры выполняют только стандартные действия (insert, select, update, delete), а вся бизнес логика "сидит" не в них, а BL.
И уж если вы переезжаете с одного типа БД на другой, то в любом случае нужно будет создавать новую БД. А в DAL переделать connection и возможно параметры для ХП. Названия ХП и таблиц логичнее сохранить. Если нет, то нет.

Вообще топик был про другое:
что лучше и безопаснее?
- писать SQL команды в коде;
- использовать ХП.

На этот вопрос ответ однозначный - лучше использовать ХП (мое мнение).



Это сообщение отредактировал(а) thomas - 17.12.2009, 16:32

"ответ однозначный" != "моё мнение"   




В бизнес системах используется и тот и другой подходы, плюсы/минусы описаны выше.

Эдинственно неправильным в подходе автора топика есть передача параметров запроса с помощью подстановки строк


Все остальное вполне усваиваемо