界面有一个 ObjectDataSource1 和 GridView1 控件,数据访问类已实现,且已知 GridView1 的 DataSourceID 指定为 ObjectDataSource1 时能显示出查询结果来,而在
Page_Load() 中用代码执行: GridView1.DataSource = ObjectDataSource1.Select();
GridView1.DataBind();数据表格没有显示出来,但 Step Into 到代码中,发现数据类的相应 Select 方法确实执行了,不知为何就是不显示?有谁碰到过这样的问题吗?可能什么原因呢?
Page_Load() 中用代码执行: GridView1.DataSource = ObjectDataSource1.Select();
GridView1.DataBind();数据表格没有显示出来,但 Step Into 到代码中,发现数据类的相应 Select 方法确实执行了,不知为何就是不显示?有谁碰到过这样的问题吗?可能什么原因呢?
GridView1.DataBind();显示不出来,只要把 AutoGenerateColumns 属性设为 true 就行了。另外,如果 AutoGenerateColumns = "false" 时,GridView 有一个自定义列,也会按记录数循环该列。
只要设置
GridView1.DataSourceID = "ObjectDataSource1";即可!
1.自动Select
2.无须绑定!
还是好好学学三层架构吧。
极是
用ObjectDataSource使三层更加清晰,代码更简洁!
事实上接到一个项目,并不会规定你是用传统的代码开发还是其他手段来开发,唯一的要求就是按时完成,测试通过,用强类型的DataSet结合ObjectDataSource来开发你会觉得开发效率大大提高,代码大幅减少,调试修改也较传统的容易,我所在的单位不算小,用强类型的DataSet结合ObjectDataSource来开发项目的小项目组逐渐增多.当然DataSet结合ObjectDataSource就目前来说还不能完全替代传统的代码方式,但一个项目的绝大部分都可以使用这种手段,用户反应好象和传统的没什么两样!!
在实际的开发中,我们更愿意使用自己可掌握的代码
为以后的开发和扩展提供良好的可扩展性。
使用ObjectDataSource虽然能少写很多代码
但是可扩展性已经灵活性已经打了一个折扣。
使用ObjectDataSource之类的也需要打入代码,这些代码难道不是你掌握的吗?呵呵!
所谓的可扩展性和灵活性你要看指哪个方面,有些方面我觉得强于传统的代码方式,
例如ObjectDataSource调用储存过程就非常灵活和方便,可以做到返回一个DataSet一句代码都不要,而且改变调用不同储存过程就非常灵活!!
事实上我也用的不多,这仅仅是用过以后的一点感觉!!
ObjectDataSource 控件使用反射创建业务对象的实例,并调用这些实例的方法以检索、更新、插入和删除数据。 TypeName 属性标识 ObjectDataSource 使用的类的名称。 ObjectDataSource 控件在每次调用方法时都创建并销毁类的实例,它在 Web 请求的生存期内不在内存中保留对象。 如果您使用的业务对象需要很多资源或者在其他方面需要很大开销来创建和销毁,您就需要认真考虑。 使用高开销对象可能并不是最佳设计选择,但是可以使用 ObjectCreating、ObjectCreated 和 ObjectDisposing 事件控制该对象的生命周期。 引自 msdn
----------------------------------------------------------------诚然 在具体细节方面 它们大相径庭我想说的相似之处是 ejb 对于实体bean 的维护 和 ObjectDataSource 对于业务对象实例的创建.
===============================
哦哦!!
ObjectDataSource丝毫没有容器的特性,
ObjectDataSource只是一个桥梁,桥梁一端是页面,另一端是业务逻辑层或数据访问层,
它仅仅是把数据从一端传递到另一端哦!