Question

我总是有这样的想法，与使用SqlDataSource编写SQL查询相比，在后面的代码中编写SQL查询并不好

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

DataSet ds = new DataSet();

ad.Fill(ds, "Categories");

myGridView.DataSource = ds;

myGridView.DataBind();

VS

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

我觉得使用SqlDataSource是安全的，易于维护。我关心的是真的吗？请说明理由。

Answer 1

我不会在完全停止的代码中编写SQL查询。数据访问层怎么样？

如果要更改后备存储，会发生什么？您将不得不重新编写所有代码隐藏的代码。

如果您需要在多个地方使用数据，会发生什么？你重复了代码。

在您的代码中编写SQL查询之前，您需要认真考虑如何构建解决方案。在质疑SqlDataSource对象的“安全性”之前，请考虑分离和可维护性。严重。

Answer 2

SqlDataSource中的代码隐藏和SQL查询中的SQL查询几乎相同

他们在安全方面都是一样的;至于更容易维护，在大多数情况下SqlDataSource可能会更容易

数据访问层是首选，但SqlDataSource有时是一个很好的权宜之计。如果您还没有数据访问层，并且它只是用于简单/一次性的事情，我不会用累积的报纸打击您使用一个; - ）

Answer 3

您的方法都不比其他方法更安全或更不安全。由于您的aspx页面的编译方式与页面后面的代码一样，因此您不会冒险使用SqlDataSources意外地暴露您的SQL语句或数据库结构。但是，安全性不是你的主要问题 - 它的可维护性。

当微软发布SqlDataSources作为.NET 2.0的一部分时，有很多人抱怨：我们认为它会鼓励和强化坏习惯。

对于任何类型的大于单个Intranet页面的项目，您应该查看其表现良好的大哥ObjectDataSource。在使用ODS时，您几乎被限制为远离视图的数据开发单独的模型。

Answer 4

aspx或aspx.cs中的SQL都是新手，糟糕的方法。查看n层/ n层设计，关注点和任何有关软件设计的书籍。

Answer 5

根据我的经验，SQLDataSource适用于快速的一次性页面来显示数据并可能对其进行编辑。但是一旦你遇到任何复杂的场景（而且我一直都有），它会很快崩溃。可维护性是一个噩梦，在后面的代码中同时使用SQLDataSource和直接SQL。我被SQLDataSource多次烧毁了。

我至少会将数据访问层写为您可以调用的单独程序集。如果需要，这将为您提供一种可插拔的方式来更改它。更好的是数据访问解决方案，如NHibernate或LinqToSql，它可以为您处理管道并防止您自己编写整个内容。

Answer 6

DataSource控件非常适合大多数事情。它们支持网格和服务器端缓存中的分页，并可以节省数据库的访问。然而，一个缺点是如果你正在做任何复杂的数据库事务，你将无法在多个sqldatasource中使用一个事务，至少不容易。

由于池化，两个数据源可能具有不同的连接，并且在命令执行之前没有简单的方法来分配事务对象。

Answer 7

我使用SQLDataSources填充网格，需要简单的查询。使用存储过程而不是将查询放在SQLDataSource中解决了可重用性问题。 Telerik控件的示例广泛使用数据源，但这可能是由于需要简单而不是现实世界的约束。我遇到的另一个用途是放在客户端的每个站点上的页面上，这个页面并不特别关注安全性，使得员工可以动态执行sql。它包含一个简单的SQL查询 - 打开页面是检查数据库是否可访问的简单方法。

在代码后面和SqlDataSource编写查询

7 个答案: