小弟真是没有什么更好的办法,来此请教高人,帮忙给个见意在这个程序中我尽量很少用datatable,
而是用了对像集合来进行数据绑定控件的显示但在开发的时候遇到这样的一个问题。如果只显示用户的信息列表这样很容易。
因为有(user实体对象)
代码像这样
this.GridView1.DataSource = user.GetUserListByDptID(this.RadioButtonList1.SelectedValue, true);---这里返回的是 IList<UserData>
this.GridView1.DataBind();
这样直接就可以帮定,而且可以显示出来但如果有这样一个列表用户的信息(user实体对象),用户所在部门的信息(部门实体对象),用户有的权限信息(权限实体)要是用对象集合帮定显示的话。应该怎么弄?我想的几个办法:
1。
扩展用户类 加部门信息,权限信息(要显示的),但这样显示的很不爽。因为用户类实体类里的信息和其它的几个类里(部门实体对象,权限实体)的信息有冗余,
2。再做一个showUser类
这个类继承用户类,加一些好多的扩展的信息用于显示,不知我的问题。说明白了没有?请帮帮忙给个方法吧。谢谢啦。我应该怎么做更好一些呢???
而是用了对像集合来进行数据绑定控件的显示但在开发的时候遇到这样的一个问题。如果只显示用户的信息列表这样很容易。
因为有(user实体对象)
代码像这样
this.GridView1.DataSource = user.GetUserListByDptID(this.RadioButtonList1.SelectedValue, true);---这里返回的是 IList<UserData>
this.GridView1.DataBind();
这样直接就可以帮定,而且可以显示出来但如果有这样一个列表用户的信息(user实体对象),用户所在部门的信息(部门实体对象),用户有的权限信息(权限实体)要是用对象集合帮定显示的话。应该怎么弄?我想的几个办法:
1。
扩展用户类 加部门信息,权限信息(要显示的),但这样显示的很不爽。因为用户类实体类里的信息和其它的几个类里(部门实体对象,权限实体)的信息有冗余,
2。再做一个showUser类
这个类继承用户类,加一些好多的扩展的信息用于显示,不知我的问题。说明白了没有?请帮帮忙给个方法吧。谢谢啦。我应该怎么做更好一些呢???
解决方案 »
- ConnectionString 属性未被初始化
- gridview应用的样式为什么不起作用
- 关于水晶报表TextCondition是否可以换行
- 关于日期计算的问题
- 新手问题: (就10分了,新手问题多分又少,不公平).数据表格
- “/”应用程序中的服务器错误。
- 急寻论文思路
- VS.NET 2003中不能创建ASP.NET项目,怎么办?
- 从一个DataGrid中把数据导入了一个Excel文件,在Excel显示时怎样把相同数据的单元格合并
- 请问在客户端怎么处理xml文件的内容?用javascript可以吗?如果不行,怎么处理?
- (关于asp.net2.0发邮件问题,急!!) 续!!!
- ???编码转换的问题!(在线等……)
--------------------------------------------
感觉你的Model应该是在设计时出了问题,比如用户相关的一些需要的数据在Model中关连不起来,如果扩展了关连起来了又与其它Model如部门、权限产生冗余。所以建议把Model整理完善,有时不可必免有冗余字段,但完整的总比欠缺的强,试想今天你要做一个列表发现少了些字段就重建一个showUser类,明天做另一个列表发现又少是不是又做一个showUser1呢?所以第一种方法是理智的。
我就用过 新闻MODEL类里加上了评论等等 太乱了
可能是因为我的设计水平不行。所以会遇到这样那样的问题。这种方式有好处也有坏处。
好处:
提高程序的安全性,属性通过GET来取到值,SET方法来置值.
从而把属性的读写操作分开了
符全面向对象的设计,添加从数据表到类的映射
就是感觉调用的时候方便了,看起来形象了
代码结构清晰,操作数据像在操作一个个对象,强类型(一个对象一个点就会出属性)
层次鲜明,易维护,架构清楚坏处:
增加系统内存开销,增加代码量,开发难度大一些,要提前想好多的东西。
luck0235(风平浪静时人人都能掌舵上面的是我个人的观点。是我觉得这样的。
luck0235(风平浪静时人人都能掌舵)
谢谢各位仙家的意见我都会做为参考,
luck0235(风平浪静时人人都能掌舵)
的话,说出方法一的好处,和方法二的坏处。主要还是看lz的需求了如果就这次整显示的字段,就用第二种,写个showUser类来实现。如果以后经常性的需要调整,就用第一种的了。(数据冗余)
我也有同样的问题
假如你要绑定显示出来部门的名称就是
((DepartmentEntity)Eval("DepartmentInfo")).DepartmentName;
其中DepartmentEntity是部门实体类,DepartmentInfo是用户实体类中部门实体类的一个对象,DepartmentName是部门实体类中的一个属性。
如果你再要增加信息,那是再加一个类
还是扩展showUser类
如果是扩展showUser类,不又是第一中方案了?
建议改进第一种方法。
楼主自己就是高人,本来dataTable 就挺好,为什么非要搞的这么复杂呢?
从而把属性的读写操作分开了
符全面向对象的设计,添加从数据表到类的映射
就是感觉调用的时候方便了,看起来形象了
代码结构清晰,操作数据像在操作一个个对象,强类型(一个对象一个点就会出属性)
层次鲜明,易维护,架构清楚
好处:
提高程序的安全性,属性通过GET来取到值,SET方法来置值.
从而把属性的读写操作分开了
符全面向对象的设计,添加从数据表到类的映射
就是感觉调用的时候方便了,看起来形象了
代码结构清晰,操作数据像在操作一个个对象,强类型(一个对象一个点就会出属性)
层次鲜明,易维护,架构清楚坏处:
增加系统内存开销,增加代码量,开发难度大一些,要提前想好多的东西。----------------------------
你可以写强类型的DataSet,标题上写的是DataGrid但是里面我看到好像用泛型了,是2005吧,用强类型的DataSet很方便,至于兴能没测过,应该不会慢到那里去,数据多就用分页呗