ObjectDataSource是比较有意思的一个东西

通过在网络上遍访各位高手，终于自己有了一些心得体会。现总结如下：

1、ObjectDataSource的作用是给页面的数据展示控件提供数据

2、ObjectDataSourc是一个媒介，它一手拉着界面的数据展示控件，一手拉着实际的数据来源。它自己什么都不是，仅仅是一个中介。

3、之所以它叫ObjectDataSource,是因为它不像AccessDataSource和SQLDataSource那样是直接连到了数据库，而是连到一个特殊的对象。有DataObjectAttribute()属性的对象

4、因此，利用ObjectDataSource完成的数据访问方案很容易做到3层架构了。ASPx页面控件层（UI）、数据对象层（BLL）[订正: (BLL)业务逻辑层]、数据访问层（DAL）

       但是平时我们的各种项目，并不是都很大型的。对于众多中小型项目来说，并没有特别特殊或复杂的BLL(业务逻辑层)．我们使用的仅仅是增、删、改、查这些基本功能。因此的确没有特别的必要硬弄个什么业务层出来。

        但是这种情况下，如果满世界的去使用方便的SQLDataSource或者AccessDataSourc会导致数据查询功能被散布在整个页面间。并且如果有多个页面的查询完全相同也无法做到组建重用。总之往高了说违反OO精神，小了说代码维护难度太大。

        因此我总结了一个结合.net2.0特有的TableAdapter对象和ObjectDataSource组和使用的方式来解决这个问题

        简单说，利用.net2.0的TableAdapter对象的特性，在项目中自动生成一个XXTableAdapters的命名空间，里面包含了本项目所有用到的数据访问对象和方法。在页面上使用ObjectDataSourc对象来引用这些数据访问对象，自动生成的TableAdapter对象本身就是具有DataObjectAttribute()属性的对象。这样就做到了一个较为集中的数据访问层的实现，以及页面和数据访问层的分离。这时候加上ASP.net本身就具有的表示层页面和CodeBehind（代码后置）的特性，可以说基本实现了所谓的三层构架。严格说可能只有业务外观层（BizFaced).没有业务逻辑层，[订正:只有Business Facade,没有Business Rule.]，或者说业务逻辑层非常简单而已。

       个人觉得这么样子已经可以解决大多数的项目了

       下面具体介绍实现步骤：

1、创建ASP.net 网站。不是项目哦。虽然不影响实际操作，但网站和Web项目实际是有所不同的。

2、在项目App_Data文件夹内新建SQL2005数据库

3、创建表TestTable：ID  int identity PK，UserName char(50) not null  然后放入一些数据

4、数据输入完成后，在App_Code文件夹内添加DataSetSQL.xsd

5、在自动运行的向导内配置访问数据库文件DatabaseTest，并读取里面的TestTable

 前文有具体讲解如何进行详细的配置，请参考：

可以在向导中选择自动生成存储过程，这个东西能提高站点运行性能，该用还是用的好，再说又不麻烦。

6、由于是SQL数据库，许多高级特性都可以在这里使用。会用的同学们就多用用好了。

7、命名新的存储过程

8、关键步骤！！！！这里的后两个复选框对我们用ObjectDataSourc对象来访问TableAdapter至关重要，因此是必选的

配置过程完成了

此时如果选中TableAdapter来查看属性的话能看到这种情况。4个命令都已经配置完成，且都拥有各自的Parameters集合

接下来在Default.aspx页面上增加一个GridView

选择新建数据源

使用对象作为数据源，然后选择TableAdapters里面的对应的TableAdapter

分别选择对应的方法

完成后可以运行程序看看

赫赫，数据已经出来了。下面回到Default.aspx页面为GridView添加编辑和删除按钮

也可以使用下面这两个属性来添加编辑和删除。不过两种方法竟然不同步，各自管自己哦。

然后再次运行程序，点编辑和删除试试？

我执行的结果是删除白点，更新出错

问题在哪里呢？

1、由于我在生成TableAdapter的时候使用了开放式并发，因此在更新和删除的存储过程中需要原始数据进行验证。

2、DataObjectSource控件有一个属性用于指定如何解决数据冲突，简单说就是是否支持开放式并发。

MSDN：通过将 ObjectDataSource 控件的 ConflictDetection 属性设置为 true，可以指定 ObjectDataSource 控件应该包括调用源数据对象的更新方法时的原始值。此后，这些原始值可以包括在开放式并发检查中。有关更多信息，请参见对 ObjectDataSource 控件使用参数。有关开放式并发检查的信息，请参见使用开放式并发。

因此，修改DataObjectSource控件属性如下

再次运行，删除操作完成了，但是更新依然不正确

继续找问题？从前面的错误信息页可以推理，需要调用一个有三个参数的Update方法，而实际上没有。通过检查ObjectDataSouceSQL控件的配置信息发现我们指定的Update是有4个参数的。比较后少了一个ID字段。

具体的原因还没有弄仔细，不过发生的源头是因为GridView控件不会返回现有的ID值。很明显哦，ID是主关键字列，不允许编辑的。因此自然没有当前值，只有原始值。不过这个问题最好微软能解决以下，否则都要我们自己来改代码不太麻烦了哦。

这个时候如果将ID列的ReadOnly属性设为false，整个程序就可以运行了。不过这不应该的阿。

我的解决方案是修改存储过程，例如原始自动生成的如下：

ALTER PROCEDURE dbo.TestTableUpd
(
    @UserName nvarchar(50),
    @Original_ID int,
    @Original_UserName nvarchar(50),
    @ID int
)
AS
    SET NOCOUNT OFF;
UPDATE [TestTable] SET [UserName] = @UserName WHERE (([ID] = @Original_ID) AND ([UserName] = @Original_UserName));
SELECT ID, UserName FROM TestTable WHERE (ID = @ID)

由于ID不进行编辑，因此原始ID就是现有ID。另外如果不需要这么强劲的开放并发冲突检验，也可以进一步简化代码。

修改后如下，其实只要修改最后那个select中的部分。从这里也可以看出如果生成时不选择更新后刷新数据集也不会有这个问题

ALTER PROCEDURE dbo.TestTableUpd
(
    @UserName nvarchar(50),
    @Original_ID int,
    @Original_UserName nvarchar(50)
)
AS
    SET NOCOUNT OFF;
UPDATE [TestTable] SET [UserName] = @UserName WHERE (([ID] = @Original_ID) AND ([UserName] = @Original_UserName));
SELECT ID, UserName FROM TestTable WHERE (ID = @Original_ID)

在VS2005内修改存储过程

不过存储过程修改后，参数发生了变化，这时候需要重新配置TableAdapter

检查参数是不是新的了

完成以后再到Default.aspx页面重新配置ObjectDataSourcSQL

修改完毕后再次执行。应该都正确了。

总结：

1、在DataSet使用TableAdapter向导时可以自动生成4种基本查询语句，因此没必要自己写

2、由于GridView不能返回当前版本的主关键字，因此在更新查询中要手动修改有关语句。但是如果不使用更新后刷新数据集则不需要这个操作。在本例子中其实只是简单的进行表格的输入和输出，最早的出发点也是想用于小型的应用。因此如果不采用刷新数据集则可以更加简单。

3、由于ObjectDataSourc控件调用的TableAdapter控件中方法需要名称对应，因此GridView是如何返回多个值呢？它自己能保存值的多个状态，在传递给ObjectDataSourc时，ObjectDataSourc通过OldValueParameterFormatString属性来给参数添加前缀，总之参数的名字要统一的。

4、估计很多可以和ObjectDataSourc绑定的界面控件都可以这么来使用。

5、其实还有很多细节的，不过一来我也不一定能都说清楚，二来大家可以自己尝试。本贴到此结束。

希望对大家有所帮助

2007年8月日