Написание запросов в коде против SqlDataSource

Question

У меня всегда есть представление, что написание SQL-запросов в коде не очень хорошо по сравнению с написанием его с использованием SqlDataSource

SqlDataAdapter ad = new SqlDataAdapter("SELECT * FROM Categories", myConnection);

DataSet ds = new DataSet();

ad.Fill(ds, "Categories");

myGridView.DataSource = ds;

myGridView.DataBind();

против

<asp:SqlDataSource ID="SqlDataSource1" runat="server"
  ConnectionString="<%$ ConnectionStrings:myConnection %>"
  SelectCommand="SELECT * FROM Categories" />

Я считаю, что использование SqlDataSource безопасно, легко обслуживается. Является ли мое беспокойство правдой? Пожалуйста, обоснуйте.

Answer 1

Я бы не писал SQL-запросы в коде после полной остановки. Как насчет уровня доступа к данным?

Что произойдет, если вы захотите поменять свой бэк-магазин? Тебе придется переписать весь твой код.

Что происходит, когда вам нужно использовать данные в нескольких местах? Вы дублируете код.

Вам нужно серьезно подумать о том, как вы разрабатываете свое решение, прежде чем писать SQL-запросы в своем коде. Подумайте о разделении и удобстве обслуживания задолго до того, как вы зададите вопрос о «безопасности» объектов SqlDataSource. Серьезно.

Answer 2

SQL-запросы в выделенном коде и SQL-запросы в SqlDataSource в значительной степени эквивалентны

они оба примерно одинаковы в плане безопасности; что касается простоты обслуживания, SqlDataSource может быть немного проще в большинстве случаев

уровень доступа к данным предпочтителен, но SqlDataSource иногда является достаточно хорошей целесообразностью. Я бы не стал подбрасывать вам свернутую газету за то, что вы ее используете, если у вас еще не было слоя доступа к данным, а для чего-то простого / одноразового;

Answer 3

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

Многие люди жаловались, когда Microsoft выпустила SqlDataSources как часть .NET 2.0: мы считаем, что это поощряет и усиливает вредные привычки.

Для любого типа проекта, который больше, чем одна страница интрасети, вы должны посмотреть на его хорошо себя ведущего старшего брата, ObjectDataSource . Используя ODS, вы почти вынуждены разрабатывать отдельную модель для ваших данных, вне вашего представления.

Answer 4

SQL в aspx или aspx.cs - действительно новичок, плохой подход. Посмотрите n-уровневый / n-слойный дизайн, разделение проблем и любую книгу по разработке программного обеспечения.

Answer 5

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

Я бы по крайней мере написал Уровень доступа к данным как отдельную сборку, в которую можно обращаться. Это даст вам подключаемый способ заменить его, если вам нужно. Еще лучше было бы решение для доступа к данным, такое как NHibernate или LinqToSql, которое обрабатывает сантехнику для вас и предотвращает необходимость писать все целиком самостоятельно.

Answer 6

Я использовал SQLDataSources для заполнения сетки, нуждаясь в несложном запросе. Использование хранимой процедуры вместо правильного размещения запроса в SQLDataSource решает проблему повторного использования. В примерах элементов управления Telerik широко используются источники данных, но это может быть связано с необходимостью простоты, а не с реальными ограничениями. Еще одно использование, с которым я столкнулся, было на странице, размещенной на каждом сайте у клиента, не особо заботящегося о безопасности, который позволял персоналу выполнять sql на лету. Он содержал простой SQL-запрос - открытие страницы было простым способом проверить, доступна ли база данных.

Answer 7

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

из-за объединения в пул два источника данных могут иметь разные соединения, и нет простого способа назначить объект транзакции до выполнения команд.