|
|
|
|
|
|
|
如果――BO里的字段都改成是string――会怎样？
|
2005年11月24日 00:08
|
|
|
标签列表
业务对象(10)
对象设计(41)
|
|
BO里的字段总会有各种类型：int、DateTime、string、float、decimal等。最近和个朋友正在架构公司的底层平台，朋友坚持所有的字段都用字符串来表示。小弟我总觉得这样做不妥，和朋友争论了一番。原来正常一个类变了个样：
class EmployeeInfo class EmployeeInfo
{ {
int id; string id;
DateTime birthday; string birthday;
string name; string name;
decimal baseSalary; string baseSalary;
int departmentID; string departmentID;
} }
我的理由是：1、运行性能会下降，当我们进行数学表达式，id值定位或查找，就要进行字符串到具体类型的转换。系统的主健全部是用int型流水号，因此数据载入内存后，定位查找时如果用字符串判断相等肯定比整型来得慢很多。2、空间的占用会加大，一个int32整数只占4 bytes，而一个百万级的数字字符串就要占7 bytes，要命的是C#里面全部是unicode的字符串，相当于占14 bytes。如果将十万笔的数据载到内存，这样的空间占用我想应该是可怕的。
朋友理由是：1、不见得会降低性能，相反在企业应用程序中，大量的数据只是做显示之用，反而会提高性能。因为数据从数据库读取到本地，需要将类型转成是具体类型，然后在显示到界面肯定是要将其转成字符串才能显示到表现层。如果都是字符串，那么就无需进行任何转换。如果要进行逻辑运算时再转也不迟。况且数据库应用程序，如果要性能，很多算法写成存储过程；2、架构变得很简单，由于我们的架构里支持动态表结构，因此必须通过反射的机制在读取数据，显示数据里进行相应类型的转换。很多地方都要处理类型的问题（的确很复杂，我研究了三周，做了大量的比较，理出了动态表结构的模型，其中大量时间在研究类型的运行时动态处理的问题）。如果直接用字符串，一切变得很简单。
最后我决定接受他的做法，理由只有一个：他开发Web应用程序多年了，以用此方式做过N套系统，运行都不错。小弟以前开发Game，应用程序开发很多都是向他取经的。我说服自己是我自己对性能太看重了，做应用程序应该以项目进度为主，不能太专牛角，而且性能可以通过要求客户的服务器配置来提高。
发贴于此，希望诸位前辈能对此做法给些点评。
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年11月24日 00:11
|
|
|
没想到论坛会将空格去掉。上面写的两个类有点乱，重写一下：
class EmployeeInfo
{
int id;
DateTime birthday;
string name;
decimal baseSalary;
int departmentID;
}
class EmployeeInfo
{
string id;
string birthday;
string name;
string baseSalary;
string departmentID;
}
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年11月24日 11:24
|
|
|
>坚持所有的字段都用字符串来表示
这是我一直主张的，所以在我的Jdon框架中，缺省的都是字符串，这样也使得Jdon框架本身和使用变得简单，非常希望有更多人能接受这个观点。
另外一个就是：每个Model对象都要有自己的主键，有这个规定也可简化开发得多。
你提出的性能问题也是正确的，但那是微观的，我们不但要有细节洞察力，而且需要跳出微观的架构高度观察力，对于java架构级别的体系，动不动就是架设新服务器（硬件成本很低了），那点内存节约没有意义。
关键是我们的系统要有可伸缩性，要简化开发，多快好省做出软件。
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年11月24日 16:40
|
|
|
哈哈，原来有板桥兄支持，难怪我朋友那么坚持。好吧，我就坚定我的项目里就采用这此做法，但我还是保留个人对性能上的观点。
如果在做game，为了保证50fps以上，0.01s就要处理所有的大量复杂的AI逻辑，大量的图象显示特效。因此连函数的调用开销，内存是分配在堆栈上还是heap上都会考虑，memcpy()这样的函数都要用mmx指令优化。以至于我到现在养成的时时考虑性能的编程习惯。我个人认为这是个好习惯，就如生活中节约每滴水一样，因为这样的习惯并不会占用我太多的精力和时间，相反在积少成多时，它的作用还是蛮可观的。
不过我也同意你所说的，一切不能太微观，站在架构的高度。我认可以的优化顺序：先优化架构――再优化算法――再优化代码书写――实在不行才用汇编。不必处处代码都优化，只需要优化性能的瓶颈。
当然现在我们是在做企业的应用程序，性能虽然不必那么考虑，但既然是一个架构，性能和易用同样是评价的关键。快速开发简易方便是针对架构的应用，而不是架构本身的实现。
不管怎样，我还是接受你的观点，如果未来真遇上了性能问题，再来重构。
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年11月30日 01:13
|
|
|
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年11月30日 13:32
|
|
|
显示层的model我感觉都用string挺好的
但是业务层的model也都用string需要实际情况商榷吧
尤其我们对业务对象需要大量复杂的商业逻辑操作，否则也不需要抽象出来这层了。
提出两层的model是根据JSF的说法。
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年11月30日 13:46
|
|
|
全用String和用xml来传递数据岂不是一样。就像java间的远程访问有了hession就不用burlap，这个东东有必要吗？
很多时候全用String会很麻烦的，比如显示逻辑比较复杂时（计算找零之类的）。8用走极端吧~~
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年12月01日 10:05
|
|
|
还是该怎样就怎样吧!借用jdon框架的JdbcTemp类做DAO 只支持Long ,String ,Integer 三种
if ( key instanceof java.lang.String ) {
String keyStrs = ( String ) key ;
if ( !keyStrs.equals( "" ) ) {
ps.setString( i , keyStrs ) ;
}
} else if ( key instanceof java.lang.Integer ) {
ps.setInt( i , ( ( Integer ) key ).intValue() ) ;
} else if ( key instanceof Float ) {
ps.setFloat( i , ( ( Float ) key ).floatValue() ) ;
} else if ( key instanceof Long ) {
ps.setLong( i , ( ( Long ) key ).longValue() ) ;
}
最后在BO里面"修补",getter,setter方法搞的乱七八糟!.
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年12月01日 10:38
|
|
|
mythmoon 倒是指出了Jdon框架的特点，当然有异议是正常的。
有关"getter,setter方法搞的乱七八糟!. "问题，我是提倡这样解决：
1. 使用O/R mapping的配置，在配置里解决。
2. 将数据库字段尽量都设成字符型。
数据库字段也都设置成字符型与BO字段都设成字符型好处是一样的，当然有人担心数据库性能，但是我们有缓存啊，缓存已经减少了数据库的频繁访问，数据库性能只有在频繁访问高负荷下才明显显露出来，因为我们使用的是J2EE中间服务器，大量负载转移到J2EE应用服务器上了。
这和我前面述说的“数据库时代已经过去“一文是一脉相承的。
http://www.jdon.com/artichect/dbover.htm
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年12月01日 19:11
|
|
|
BO里的字段和数据库字段都设置成String类型，我总觉得不是太妥。
首先，我们做程序是为了解决现实中的问题，需要对领域问题建模，这应该按对象的本来属性来建。如果一个属性本来为整型（为了编程实现的方便）硬要规定为字符串型，是不是有悖于反映问题的本质？并给后续的工作（交流等）带来问题？
其次，如果把任何数据库字段都搞成字符串，那么对某些字段的一些限定规则（例如日期、取值范围等）如何保证？
我们对领域问题建模，并把关系数据保持在数据库中，本质上是对现实事物的一种反映，对大部分企业、行业来说都是有很大历史价值的，需要被后继的其他应用来使用。如果都按字符串来建模的话，如何保证这些数据的价值？如何让其他后继的应用来继续（方便地）使用这些数据？
既然大家都说，现在硬件资源已经能保证了，不需要考虑都设置成字符串带来的性能开销了。那么我问一句：怎么在显示时把其他类型转换成字符串这点开销大家反而接受不了了呢？
大家都不是从解决需求问题出发来考虑问题而是为了自己编程的某种方便来“扭曲”问题的本质，是不是有点“奇技淫巧”的味道呢？
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年12月01日 23:23
|
|
|
做应用系统,V层的技巧,比M ,C 更重要!个人感觉沉淀就很重要了!
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年12月02日 09:25
|
|
|
|
像我现在做的数据库3000w数据的系统，数据库都是字符型，然后财务报表需要进行很复杂的运算，model都是字符型，这样……效率和各种转换的成本不敢想象
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年12月02日 09:58
|
|
|
我知道各位意见很大，所以，这个观点我一直没有提出来，只是几个熟悉朋友大家心知肚明，所以借这个帖子写出来。
不是向大家推荐一定这样做好，各人还是按照自己想法来说，只是告诉大家有这么一个解决方案可供参考。
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年12月02日 15:39
|
|
|
|
|
|
|
|
|
Re: 如果――BO里的字段都改成是string――会怎样？
|
2005年12月06日 10:39
|
|
|
|
其实在应用中,我都是这样安排的,POJO用的是与数据库统一的类型,但在formBean中用的就是板桥大哥说的全部都是字符串类型,反正用起来还行,挺方便的.
|
|
|
|
|
这个主题有 24 回复 ／ 2 页
Go
1 2
►
|
|
|
注册
登陆
返回本主题
返回页首
.text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://my.poco.cn/fav/storeIt.php?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t)+'&img=http://www.h-strong.com/blog/logo.gif','keyit','scrollbars=no,width=475,height=575,status=no,resizable=yes'));keyit.focus();){kind=logo}
