小弟真是没有什么更好的办法,来此请教高人,帮忙给个见意在这个程序中我尽量很少用datatable,
而是用了对像集合来进行数据绑定控件的显示但在开发的时候遇到这样的一个问题。如果只显示用户的信息列表这样很容易。
因为有(user实体对象)
代码像这样
this.GridView1.DataSource = user.GetUserListByDptID(this.RadioButtonList1.SelectedValue, true);---这里返回的是 IList<UserData> 
        this.GridView1.DataBind();
这样直接就可以帮定,而且可以显示出来但如果有这样一个列表用户的信息(user实体对象),用户所在部门的信息(部门实体对象),用户有的权限信息(权限实体)要是用对象集合帮定显示的话。应该怎么弄?我想的几个办法:
1。
扩展用户类 加部门信息,权限信息(要显示的),但这样显示的很不爽。因为用户类实体类里的信息和其它的几个类里(部门实体对象,权限实体)的信息有冗余,
2。再做一个showUser类
这个类继承用户类,加一些好多的扩展的信息用于显示,不知我的问题。说明白了没有?请帮帮忙给个方法吧。谢谢啦。我应该怎么做更好一些呢???

解决方案 »

  1.   

    扩展用户类 加部门信息,权限信息(要显示的),但这样显示的很不爽。因为用户类实体类里的信息和其它的几个类里(部门实体对象,权限实体)的信息有冗余,
    --------------------------------------------
    感觉你的Model应该是在设计时出了问题,比如用户相关的一些需要的数据在Model中关连不起来,如果扩展了关连起来了又与其它Model如部门、权限产生冗余。所以建议把Model整理完善,有时不可必免有冗余字段,但完整的总比欠缺的强,试想今天你要做一个列表发现少了些字段就重建一个showUser类,明天做另一个列表发现又少是不是又做一个showUser1呢?所以第一种方法是理智的。
      

  2.   

    对象关系理清楚,如果不是is a的关系最好不要继承.
      

  3.   

    楼主为什么要用集合而不直接绑定DataReader或DataTable呢?说说有啥好处,让大家也学习下~~
      

  4.   

    可以直接继承USER类 再添加属性吗?
      

  5.   

    用第一种感觉很不好 
    我就用过 新闻MODEL类里加上了评论等等 太乱了
      

  6.   


    可能是因为我的设计水平不行。所以会遇到这样那样的问题。这种方式有好处也有坏处。
    好处:
    提高程序的安全性,属性通过GET来取到值,SET方法来置值.
    从而把属性的读写操作分开了
    符全面向对象的设计,添加从数据表到类的映射
    就是感觉调用的时候方便了,看起来形象了
    代码结构清晰,操作数据像在操作一个个对象,强类型(一个对象一个点就会出属性)
    层次鲜明,易维护,架构清楚坏处:
    增加系统内存开销,增加代码量,开发难度大一些,要提前想好多的东西。
      

  7.   

    TO:
    luck0235(风平浪静时人人都能掌舵上面的是我个人的观点。是我觉得这样的。
      

  8.   

    TO:
    luck0235(风平浪静时人人都能掌舵) 
    谢谢各位仙家的意见我都会做为参考,
      

  9.   

    看了
    luck0235(风平浪静时人人都能掌舵)
    的话,说出方法一的好处,和方法二的坏处。主要还是看lz的需求了如果就这次整显示的字段,就用第二种,写个showUser类来实现。如果以后经常性的需要调整,就用第一种的了。(数据冗余)
      

  10.   

    改用repeater不就什么都解决了马。
      

  11.   

    http://community.csdn.net/Expert/topic/5012/5012777.xml?temp=.4957544
    我也有同样的问题
      

  12.   

    建立三个实体类分别是用户信息,部门信息,权限信息,用户信息中包含一个部门信息和一个权限信息实体类的对象。
    假如你要绑定显示出来部门的名称就是 
    ((DepartmentEntity)Eval("DepartmentInfo")).DepartmentName;
    其中DepartmentEntity是部门实体类,DepartmentInfo是用户实体类中部门实体类的一个对象,DepartmentName是部门实体类中的一个属性。
      

  13.   

    第二种看上去很好,其实不然
    如果你再要增加信息,那是再加一个类
    还是扩展showUser类
    如果是扩展showUser类,不又是第一中方案了?
      

  14.   

    简单的继承是不可取的,因为没有is a 的关系。
    建议改进第一种方法。
    楼主自己就是高人,本来dataTable 就挺好,为什么非要搞的这么复杂呢?
      

  15.   

    提高程序的安全性,属性通过GET来取到值,SET方法来置值.
    从而把属性的读写操作分开了
    符全面向对象的设计,添加从数据表到类的映射
    就是感觉调用的时候方便了,看起来形象了
    代码结构清晰,操作数据像在操作一个个对象,强类型(一个对象一个点就会出属性)
    层次鲜明,易维护,架构清楚
      

  16.   

    可能是因为我的设计水平不行。所以会遇到这样那样的问题。这种方式有好处也有坏处。
    好处:
    提高程序的安全性,属性通过GET来取到值,SET方法来置值.
    从而把属性的读写操作分开了
    符全面向对象的设计,添加从数据表到类的映射
    就是感觉调用的时候方便了,看起来形象了
    代码结构清晰,操作数据像在操作一个个对象,强类型(一个对象一个点就会出属性)
    层次鲜明,易维护,架构清楚坏处:
    增加系统内存开销,增加代码量,开发难度大一些,要提前想好多的东西。----------------------------
    你可以写强类型的DataSet,标题上写的是DataGrid但是里面我看到好像用泛型了,是2005吧,用强类型的DataSet很方便,至于兴能没测过,应该不会慢到那里去,数据多就用分页呗