Написание запросов в программном коде по сравнению с SqlDataSource
У меня всегда было такое представление, что писать 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 безопасно и легко в обслуживании. Верно ли мое беспокойство? Обоснуйте пожалуйста.
Ответы 7
Я бы не стал писать SQL-запросы в коде за точкой. Как насчет уровня доступа к данным?
Что произойдет, если вы захотите сменить резервный магазин? Вам придется переписать весь код программной части.
Что происходит, когда вам нужно использовать данные более чем в одном месте? Вы дублируете код.
Вам нужно серьезно подумать о том, как вы разрабатываете свое решение, прежде чем писать SQL-запросы в своем коде. Подумайте о разделении и ремонтопригодности задолго до того, как усомнитесь в «безопасности» объектов SqlDataSource. Серьезно.
SQL-запросы в коде программной части и SQL-запросы в SqlDataSource в значительной степени эквивалентны.
они оба примерно одинаковы с точки зрения безопасности; Что касается упрощения обслуживания, SqlDataSource в большинстве случаев может быть немного проще.
Уровень доступа к данным предпочтителен, но SqlDataSource иногда оказывается достаточно целесообразным. Я бы не стал ударить вас свернутой газетой за ее использование, если бы у вас еще не было уровня доступа к данным, и это было для чего-то простого / одноразового.
Стивен может не ударить вас за использование SqlDataSource, но многие другие сделают это. Я бы.
По моему опыту, SQLDataSource хорош для быстрой разовой страницы для отображения данных и, возможно, их редактирования. Но как только вы попадаете в какой-либо сложный сценарий (а у меня всегда так), он довольно быстро выходит из строя. Ремонтопригодность - это кошмар при использовании как SQLDataSource, так и прямого SQL в исходном коде. SQLDataSource меня сжигал много раз.
Я бы, по крайней мере, написал уровень доступа к данным как отдельную сборку, в которую вы можете вызывать. Это даст вам подключаемый способ изменить его, если вам нужно. Еще лучше было бы решение для доступа к данным, такое как NHibernate или LinqToSql, которое обрабатывает сантехнику за вас и избавляет вас от необходимости писать все самостоятельно.
Ни один из ваших методов не является более или менее безопасным, чем другой. Поскольку ваши aspx-страницы компилируются так же, как и ваш код за страницами, вы не рискуете случайно раскрыть свои операторы SQL или структуру базы данных просто с помощью SqlDataSources. Однако главная проблема здесь не в безопасности, а в ремонтопригодности.
Многие люди жаловались, когда Microsoft выпустила SqlDataSources как часть .NET 2.0: мы считаем, что это поощряет и укрепляет вредные привычки.
Для любого типа проекта, размер которого превышает одну страницу интрасети, вам следует изучить его старшего брата, ObjectDataSource. При использовании ODS вы почти ограничены в разработке отдельной модели для ваших данных, вдали от вашего представления.
Элементы управления DataSource отлично подходят для большинства задач. Они поддерживают разбиение на страницы в сетках и кэширование на стороне сервера и могут экономить поездки в базу данных. Однако одним из недостатков является то, что если вы делаете что-то сложное с транзакциями db, вы не сможете использовать транзакцию для более чем одного sqldatasource, по крайней мере, не легко.
из-за объединения два источника данных могут иметь разные соединения, и нет простого способа назначить объект транзакции до выполнения команд.
SQL в aspx или aspx.cs - действительно плохие подходы для новичков. Найдите многоуровневый / многоуровневый дизайн, разделение проблем и любую книгу по дизайну программного обеспечения.
+1 «любая книга по дизайну программного обеспечения». Код базы данных не принадлежит представлениям. Кроме того, это чрезвычайно затрудняет отладку. Мне нравится отлаживать свой код, когда что-то идет не так с моей базой данных.
Я использовал SQLDataSources для заполнения сетки, требующей несложного запроса. Использование хранимой процедуры вместо помещения запроса прямо в SQLDataSource решает проблему повторного использования. В примерах из элементов управления Telerik широко используются источники данных, но это может быть связано с потребностью в простоте, а не с реальными ограничениями. Еще одно использование, с которым я столкнулся, было на странице, размещенной на каждом сайте у клиента, не особо озабоченного безопасностью, что позволяло персоналу выполнять sql на лету. Он содержал простой SQL-запрос - открытие страницы было простым способом проверить, доступна ли база данных.
«Я бы не стал ударить вас свернутой газетой за использование одной», наткнулся на это, когда искал в Google «плохой дизайн SqlDataSource», поскольку в настоящее время я пытаюсь работать над проектом с использованием sqldatasource как минимум на 15 разных страницах. Спасибо, Стивен, что заставил меня смеяться (+1 за это). Искал авторитетный источник, чтобы не использовать их.