平奇

任何一种技术,只是一个工具,一个平台,一个你学习思想的例子,关注我们该关注的!

博客园 首页 新随笔 联系 订阅 管理
  3 Posts :: 0 Stories :: 23 Comments :: 0 Trackbacks

2006年4月26日 #

一、DataGridTableStyle.MappingName

DataGrid 有一个TableStyles属性,包含一个类型为DataTableStyle的对象集合,用来设置DataGrid的样式。DataTableStyle的MappingName属性设置了它与数据源的对应关系,比如我绑定一个TableName为"Table1"的DataTable到DataGrid上,这个DataGrid包含一个DataTableStyle,绑定之后,这个Style的样式还是无法应用,因为它的MappingName还没有设为"Table1"

数据源为DataSet或DataTable时,MappingName为DataTable的TableName。数据源为其它的呢?其实所有可以作为DataSource的对象(支持DataSource的规则见MSDN)有一个统一的方法,即:MappingName = 数据源对象.GetType().Name
1.强类型Array  比如说一个YourClass[] 对象作为数据源绑定到Grid上,则Style的MappingName设为 "YourClass[]",同样,这个值可以通过 对象.GetType().Name  获取
2.ArrayList    MappingName="ArrayList"
3.List<T>    这个MSDN没有说明,比如说一个List<YourClass>对象作为数据源绑定到Grid上,MappingName可以为 "List`1",这个值也可通过 对象.GetType().Name  获取

二、自动设置列宽

代码不写了,下在把实现一个通用Grid样式生成器的思路说一下:

DataGrid.CreateGraphics().MeasureString(string text, Font font) 方法可以测量字符串长度

确定数据源后,每一个列按照如下步骤进行:先从列标题开始,然后逐行遍历数据源中的数据,算出最长的宽度,最后把此列的列宽设为最长宽度加一个自定义值。

DataTable、DataSet逐行遍历数据很简单,如果是自定义集合,可以用反射得出数据。

posted @ 2006-04-26 19:57 myth 阅读(1851) 评论(0) 编辑

“软件设计的重点在于抽象”,不记得这句话是哪位说的了,我想改正一下:“保证软件灵活性设计的重点是抽象”,由此可知,抽象的作用是“保证软件的灵活性设计”。越来越多的语言、平台构建在OO思想之上,这充分说明了OO的正确性。OO,一种思想,一种谈到软件设计时必须涉及的思想,越来越多的人开始追捧它,当然,我也是其中之一。有了它,软件设计可以提升到一个“美”的境界;有了它,软件的可读性、可维护性、灵活性、可扩展性等等一大堆的“性”得到了很大的提高。这几年,“设计模式”、“架构”等等一系列的名词越来越受到人们的关注。所有这些东西,其实就是为了实现一个抽象层次的编程,以保证软件的灵活性。

那什么是抽象?我感觉抽象其实就是为了实现一句话“Don't repeat” ,不要重复。理想状态下,一个系统的任何代码、逻缉、概念在这个系统中都是唯一的,代码的唯一性很容易保证,但是逻缉、概念的唯一性就很难保证,随着抽象程度的提高,它们的唯一性也都得到了提高,软件的灵活性也随之提高。

这么说,是不是就意味着抽象程度越高越好?书上一般是这样定义的。但是,我觉得这个说法忽略了一个最重要的因素:人。软件是由人编写的,人不可能做到完美,而且一个开发团队中,每个人的水平不一样,想法不一样。这种种因素制约着我们。

我的一个同事给我说过一句话:“软件项目的成功标志是什么?有三点:客户满意,公司满意,员工满意”
客户怎么满意?软件按照预算工期、成本完成,并为为他们创造价值
公司怎么满意?软件按照预算工期、成本完成,并为公司创造利益
员工怎么满意?软件按照预算工期、成本完成,开发过程顺利,自已的利益得到保证。
得到的结论就是软件项目顺利的按照预算工期、成本完成,就算是成功了。

每一个开发团队的水平是不一样的,项目经理、架构师需要反复思考,软件设计时究竟抽象到什么程度最好?这肯定要根据现有的资源(开发人员、工具等)来确定,如果过于抽象,你水平到位,可以理解,那么下面的开发人员呢?你必须要考虑培训成本、沟通成本,过于抽象,会延长工期,甚至让项目遥遥无期。最好的做法就是采用最简单、最容易使用的技术来实现当前需求。

并不是说不需要抽象,如果不需要抽象,那么多关于软件设计的资料、书籍岂不成了空谈?没有抽象,很难保证软件的灵活性,给软件的维护造成的很大的困难,程序的可读性、。。性都很难保证。

说了一大堆,还是没有结论,这种东西也许根本就不会有结论。只能在具体工作中进行权衡,最重要的就是要清楚自已当前最紧要的任务是什么?时间是否允许?成本是否足够?开发人员的水平是否满足条件?等等一系列的问题我们都需要考虑在内。

当然,人往高处走,经过一系列的项目锻炼,你的团队的技术水平也在不断提升,你运用设计技术越来越充分,开发效率、软件质量会逐步提升。所以,我们还是需要设计,需要抽象的,只不过这是一个过程。

posted @ 2006-04-26 19:50 myth 阅读(742) 评论(4) 编辑