界面有一个 ObjectDataSource1 和 GridView1 控件,数据访问类已实现,且已知 GridView1 的 DataSourceID 指定为 ObjectDataSource1 时能显示出查询结果来,而在
Page_Load() 中用代码执行:        GridView1.DataSource = ObjectDataSource1.Select();
        GridView1.DataBind();数据表格没有显示出来,但 Step Into 到代码中,发现数据类的相应 Select 方法确实执行了,不知为何就是不显示?有谁碰到过这样的问题吗?可能什么原因呢?

解决方案 »

  1.   

    看看 selectmethod  所指定的相应方法,返回值是什么类型然后 尝试将 ObjectDataSource1.Select() 转为该类型使用 as 
      

  2.   

    我找到什么原因了,因为这个 GridView 绑定时用过 Refresh Schema 功能,生成了定义列的标签,然后 VS 把 AutoGenerateColumns 属性改成了 false,所以用代码:  GridView1.DataSource = ObjectDataSource1.Select();
      GridView1.DataBind();显示不出来,只要把 AutoGenerateColumns 属性设为 true 就行了。另外,如果 AutoGenerateColumns = "false" 时,GridView 有一个自定义列,也会按记录数循环该列。
      

  3.   

    你也可以在dataview中添加列,然后设置它的datamember属性(select来的字段名)
      

  4.   

    既然用ObjectDataSource
    只要设置
    GridView1.DataSourceID = "ObjectDataSource1";即可!
    1.自动Select
    2.无须绑定!
      

  5.   

    好像的。不过这类*DataSource控件很少有人在企业开发中用,三五个刚毕业的学生凑成的作坊不算,我是说有3年以上经验的开发人员的公司。
    还是好好学学三层架构吧。
      

  6.   

    System.Data.DataView dv = (System.Data.DataView)SqlDataSource1.Select(DataSourceSelectArguments.Empty);
    极是
      

  7.   

    事实上这是有点落伍的想法,你实实在在用过以后会发现ObjectDataSource就是为三层架构而设计的!
    用ObjectDataSource使三层更加清晰,代码更简洁!
    事实上接到一个项目,并不会规定你是用传统的代码开发还是其他手段来开发,唯一的要求就是按时完成,测试通过,用强类型的DataSet结合ObjectDataSource来开发你会觉得开发效率大大提高,代码大幅减少,调试修改也较传统的容易,我所在的单位不算小,用强类型的DataSet结合ObjectDataSource来开发项目的小项目组逐渐增多.当然DataSet结合ObjectDataSource就目前来说还不能完全替代传统的代码方式,但一个项目的绝大部分都可以使用这种手段,用户反应好象和传统的没什么两样!!
      

  8.   

    我不认为8楼的说法。
    在实际的开发中,我们更愿意使用自己可掌握的代码
    为以后的开发和扩展提供良好的可扩展性。
    使用ObjectDataSource虽然能少写很多代码 
    但是可扩展性已经灵活性已经打了一个折扣。
      

  9.   

    不同的人往往有个人的立场。如果是专门研究操作系统的,自己写一个asp.net系统,为以后的开发和扩展提供良好的可扩展性,而且还可以让微软收购你们的公司。
      

  10.   

    事实上在我的工作中几个人接收一个项目,完成后交付用户,在试用几个月中根据用户要求进行一些修改和完善,以后就一切ok了,
    使用ObjectDataSource之类的也需要打入代码,这些代码难道不是你掌握的吗?呵呵!
    所谓的可扩展性和灵活性你要看指哪个方面,有些方面我觉得强于传统的代码方式,
    例如ObjectDataSource调用储存过程就非常灵活和方便,可以做到返回一个DataSet一句代码都不要,而且改变调用不同储存过程就非常灵活!!
    事实上我也用的不多,这仅仅是用过以后的一点感觉!!
      

  11.   

    只要拿 SqlDataSource 和 ObjectDataSource 一对比,应该会发现 ObjectDataSource 就是为三结架构而设计的,ObjectDataSource 的功能是让你的页面与数据操类连接起来,不像 SqlDataSource 会在标签里写 SQL。当我了解到 ObjectDataSource 后,我想我是不会去使用 SqlDataSource 控件的,ObjectDataSource 不影响你的设计。
      

  12.   

    ObjectDataSource 很像 jee 中的 "容器"
      

  13.   

    还没想到 ObjectDataSource 像 jee 的哪个容器。
      

  14.   

    我想说的是 ejb 容器,说的不是很准确,是针对下面的话 的一些想法----------------------------------------------------------
    ObjectDataSource 控件使用反射创建业务对象的实例,并调用这些实例的方法以检索、更新、插入和删除数据。 TypeName 属性标识 ObjectDataSource 使用的类的名称。 ObjectDataSource 控件在每次调用方法时都创建并销毁类的实例,它在 Web 请求的生存期内不在内存中保留对象。 如果您使用的业务对象需要很多资源或者在其他方面需要很大开销来创建和销毁,您就需要认真考虑。 使用高开销对象可能并不是最佳设计选择,但是可以使用 ObjectCreating、ObjectCreated 和 ObjectDisposing 事件控制该对象的生命周期。         引自 msdn
    ----------------------------------------------------------------诚然 在具体细节方面 它们大相径庭我想说的相似之处是 ejb 对于实体bean 的维护 和 ObjectDataSource 对于业务对象实例的创建.
      

  15.   

    datasource控件的确是比较小用..
      

  16.   

    经常在大中型企业系统中应用ObjectDataSource的作坊成员路过...
      

  17.   

    ObjectDataSource像容器??
    ===============================
    哦哦!!
    ObjectDataSource丝毫没有容器的特性,
    ObjectDataSource只是一个桥梁,桥梁一端是页面,另一端是业务逻辑层或数据访问层,
    它仅仅是把数据从一端传递到另一端哦!
      

  18.   

    ObjectDataSource就是为分层开发而设计的。