博客园-组件工厂-最新评论http://www.cnblogs.com/henryfan/CommentsRSS.aspx探索逻辑组件化之路zh-cnFri, 15 Aug 2008 02:07:38 GMTFri, 15 Aug 2008 02:07:38 GMTcnblogsre: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287874思考－总结思考－总结Fri, 15 Aug 2008 05:37:20 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287874
我自己的感觉，在满足自己目前的前提下，留一些适当的余地。

当有新的需求提出，重新检查下有无类似的代码？ 如果有，而且发现重写一个新的方法，代码几乎是相同的。那么，重构。

不可能一开始就想到了所有的应用，基本做不到，大部分是在重构的过程中，逐渐体会。随着经历的增长，基本就能体会到在初始写代码的时候，预留一些可扩展的部分。

思考－总结 2008-08-15 13:37 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287839未公布未公布Fri, 15 Aug 2008 05:09:42 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287839
第一种，要调整参数，感觉改起来麻烦
第二种，感觉好很多

未公布 2008-08-15 13:09 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287815水言木水言木Fri, 15 Aug 2008 04:37:01 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287815
水言木 2008-08-15 12:37 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287778henryhenryFri, 15 Aug 2008 04:02:56 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287778第一情况的Create是描述方法的定义如何降低方法约定变更的风险.
第二情况的Create是表达两中情况在User发生变化后,各自内部的调整情况.

henry 2008-08-15 12:02 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287767henryhenryFri, 15 Aug 2008 03:54:47 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287767这倒不是我面对问题.
只是举个情况,设计往往是要面对不可知的情况,既然是不知道我们就不可能去假设.即使是有些东西是可以假设,但也应该有个度(这就完全取决于设计人员的经验)
所以设计越简单越好(不过这个简单其实并不简单,就如你前面提到的要清楚,其实并不容易)



henry 2008-08-15 11:54 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287765hrmaihrmaiFri, 15 Aug 2008 03:49:56 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287765一个函数的参数到底是传一个类进去还是传一组参数进去,其实要看这个函数的责任,也就是这个函数的处理逻辑.如果一个函数它就是对一个类进行操作那么它需要的参数也应该书一个类,如果它对一组数据进行操作那么它需要的也就是一组数据了.回到楼主的问题,Login的逻辑是对一组数据的合法性进行判断,而一个用户他已经是合法的了,所以如果我们将一个User实例传进去从语义上说是错误的.其实这也和二楼的说法是基本一样.而我对楼主的一点异议就是,Create到底要做什么?为什么要传一个User的实例?如果它是创建一个User实例,还是做什么的,我暂时还没有明白.

hrmai 2008-08-15 11:49 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287762方明方明Fri, 15 Aug 2008 03:49:00 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287762预计变化是要对业务非常熟悉的，其实并不容易做，所以我觉得演进的设计更有意思，也就是上边一位朋友说的重构的方式，随着对系统的熟悉设计会更加合理，但重构应该是随时发生的，一旦发现变化就应该对相应代码做出重构，始终使代码在当前看来是最简单的最容易维护的

方明 2008-08-15 11:49 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287743Ivony...Ivony...Fri, 15 Aug 2008 03:35:43 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287743

关于事务的问题，你可以继续关心我的系列文章，如果不出意外，在后面的文章里面就会谈到从OO到OR搞出了数据库一大堆纠缠不清的关系如何厘清。


不过我习惯在园子里找问题然后加以阐述，如果您能将您所遇到的实际问题列出来，如果有普遍性的话，我就会很乐意直接拿来阐述了。

Ivony... 2008-08-15 11:35 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287720henryhenryFri, 15 Aug 2008 03:22:54 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287720我个人认为没有优秀的设计,也很难假设能有多少变更;
其实有很多是凭经验的,如DAL的设计那样可能没有这方面经验的人员(也许这人没有从事过这方面设计),可能没有考虑到事务协同的问题.但紧紧凭这一点就把这个设计否决是不现实现;如果设计人员在面对这情况下很快就调整过来那这也算是个好的设计.
设计能对不可知道的情况可以进行快速调整的设计才是好的设计.
如果我们什么情况都能了解就更好了:)

henry 2008-08-15 11:22 发表评论
]]>re: 如何设计业务逻辑?http://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287695Ivony...Ivony...Fri, 15 Aug 2008 03:00:51 GMThttp://www.cnblogs.com/henryfan/archive/2008/08/15/1268431.html#1287695
Ivony... 2008-08-15 11:00 发表评论
]]>