the5fire的技术博客

关注python、vim、linux、web开发和互联网--life is short, we need python.


软件设计:粒度的把握

作者:the5fire | 标签:     | 发布:2011-01-04 2 p.m. | 阅读量: 4330, 4323
  在软件设计中粒度的把握就像是人际交往中热情的控制,你对人太热情了吧,别人可能觉得你有什么企图;对人太不热情了吧,别人又会觉得你这人冷血动物。这个绝对是一门学问。


  既然是一门学问那就不是吾辈刹那间可以搞清楚和明白的,因此写这篇文章也是发表自己的看法,和大家共同探讨。

  关于需求:
  需求这方面可以说是越细致越好,我觉得有两个词来描述需求设计:精细,准确。这二者缺一不可。


  对于一个项目来讲需求的设计可以是决定了以后项目的修改,重构甚至是能不能交付。因此在前期需求处,越是将客户的需求描述的清清楚楚明明白白,后期的开发工作越是心里有底。


  如果需求描述的过于精细可能会觉得太过于繁琐,这时就需要考虑“准确”了,就像是射击一样,如果每一个精细需求的末端都能命中靶心(客户的心意),那就不会有繁琐的感觉,相反这时会觉得这个设计做的很舒畅。(这种感觉只可意会)


  不过需求的细化是需要时间的,为了保证项目开发周期,起初的需求分析不可能让你有足够多的时间。

  就像是我们在做餐饮系统时一样,客户要求两周就要出,因为赶时间做培训。在没有足够的时间做需求的时候最佳的办法就是找模型,或者根据客户的描述快速建立起一个模型来。不过这种短周期开发的弊端是后期维护很困难,或者说是麻烦更好一些。

  因为起初并没有客户完整的需求,后期客户在要求增加需求的时候你必须基于已经开发出的东西来做,因为项目已经在运行了,可能推翻重来吗?这时的感觉就像是带上枷锁跳舞。

关于设计

  1. Dao层的粒度:

  上一篇文章《软件设计:DAO层该如何设计》中没有谈到粒度的设计,只是说了类结构上的设计。那么Dao层的粒度该如何设计呢?

  个人感觉这里的粒度就是每一个Dao类中的方法的个数,其对数据库内容的可操控程度。

  Dao层的设计是不涉及到业务的,但是它必须能够满足业务。就像是在上篇文章末师哥所说“dao层的操作是对业务的一个分解,把一个完整的业务分解到数据库中的相关表中”,那么既然是分解,其粒度自然就不粗了。不但不粗其粒度应该更为细致才好些。因为Dao层的设计应该是越简单越好,即便于调用,也便于维护。

  2. 业务层的粒度:

  这一块不太好说,一般业务层都是按照软件功能来划分,不过粒度不应该太细,毕竟是要被表现层调用的,还是不要让表现层知道的太多为妙,免得“死于”-你知道的太多了



  以上只是个人的一点看法,欢迎各位斧正。
----EOF-----

扫码关注,或者搜索微信公众号:码农悟凡


其他分类: