感觉SqlDataSource用起来好别扭；
但他又有很多方便的功能，而且还是一个发展趋势，大家说说该不该用SqlDataSource。

SqlDataSource方便，开销大，无所谓好坏，关键看用途

我这样来简单的叙述吧。

当然说SqlDataSource方便的人我也不反对，但是有设置SqlDataSource那点时间，其实已经完全能够写出一个DATASET的方法了
何况现在我们都是把数据访问和操作的方法写到类里面，我们要做的其实就是在这个方法里加入查询语句而已。
那么现在你还认为SqlDataSource方便吗？

在者，SqlDataSource很不利于维护，一旦需要整体的改变，那么你只有一个一个的去修改，而用dataset就不同了，你可以把逻辑，数据层区分开，可以给很多方法，也可以定义不同的接口

写一个程序的时候，应该考虑到你现在写的这堆代码，在其他项目中能够被引用，不用重复劳动。

SqlDataSource方便？？？
相对的吧

茅塞顿开

对于快速开发而言，SqlDataSource是个不错的东西。但是他仿佛打破了传统的数据层等结构。对于一个复杂的系统可能不允许这么跨越数据层直接查询到数据库内，会使整个系统结构更糟。

SqlDataSource提供的功能不应该算是别扭，那是因为还没有转变原先采用DataSet作为数据源，依靠Adapter来填充DataSet然后依靠数据显示控件来显示数据的传统做法。
可以把DataSource控件当作是一系列Command对象的集合，你可以往里面设置多大四个Sql命令。另外还有个好处是，在VS中可以将它的ConnectionString直接设置指到你的web.config中的connectionString所设定的廉洁字符串。
使用这个控件，不需要额外的其他空间来支持。如果你使用Adapter，那还需要一个Connection对象来支持（虽然你不用显式打开链接）。

另外，DataSource控件可以直接放置在网页上，虽然他不会显示。如果要使用Adapter,DataSet这些对象，就需要打开到“组件编辑器”中来创作更好。但是有个问题，.NET2.0中的Web页类不一定是一个组件类，如果你使用了组件，你得自己在代码编辑器中新建一个构造函数，然后在构造函数中调用InitializeComponent()方法来初始化组件类。

看你如何来使用。如果只是为了显示数据，并且还可以执行一些简单的删除更新操作，DataSource类和数据显示类配合帮助你完成很多“地下操作”，你甚至不用写一句代码。如果有一个较为复杂的逻辑过程，那么还是用DataSet，你可以根据数据库中表和关系创建架构，从DataSet类派生出你的类型化的DataSet，这样更加便于编程过程中操作。现对来说，DataSource的Select方法返回支持IEnumerable接口的对象，实际上是Syste.Data.DataView对象，而且是无类型化的，也就是你需要充分了解查询语句和数据结构，才容易操纵这个DataView。而且不能像DataSet那样，可以依靠Adapter来更新到数据库。

gridview bind,delete,edit,update,sort,cancel,page...

我还是觉得用SqlDataSource真的没有手写的快

其实一个.net程序员都有自己的类库，用习惯了，而且特别简单。现在如果让我实现一个gridview的显示，分页，数据操作，用自己的类库可以用几秒就写出来。

SqlDataSource是给初学者用的，说他用来快速开发，那是MS骗小孩的。