谈谈最近项目的设计思路[ZZ FROM JR]

2006/7/20镜像同步4 回复

谈谈最近项目的设计思路 http://blog.javaresearch.org/page/litf/20060720#%E8%B0%88%E8%B0%88%E6%9C%80%E8%BF%91%E9%A1%B9%E7%9B%AE%E7%9A%84%E8%AE%BE%E8%AE%A1%E6%80%9D%E8%B7%AF 在框架设计方面，我信奉的第一条原则是：尽量的少写代码，是减少BUG和增强系统稳定性的最好方法。换个说法就是：能在框架里实现的，绝不把它交给程序员实现。框架对外开放的接口应该尽量的简单明了。第二是基于规则而不是配置文件，即尽量使用默认规则来缺省实现，而不是产生一大堆配置文件。第三是不要尝试让框架满足100%的需求，如果那样的话，框架将越来越笨重和复杂，规则也将变得无法理解。第四，框架是一步一步产生的，而不是一步到位的。这句话的意思是，在不断的想法->实现->测试->变更这样的过程中，一步一步搭建起来的。有的人认为框架就是几张图，但是如果这张图无法实现，无论多宏大的想法，那都只是一个玩具。我完全不会认同那些“架构设计师不用写代码”这样荒谬的说法。因为框架本身如果不通过代码来验证，你怎么知道你的框架是可行的呢？第五，必须非常非常重视工具的作用，而不仅仅是所谓的分层（就那几层，MVC，都说烂了，谁不会？），层次结构没有任何的神秘性。工具是保证项目持续运作的关键。特别是，现在那么多可选框架的时候。这些框架都有着一大堆的配置文件，如何根据工具的特性减少配置量，保持一致性，便变得非常重要。这就要求架构设计师必须对工具非常熟悉，熟悉这些工具或框架的最佳实践。在特殊的情况下，为了开发的便捷性和高效性，有可能还需要自己去开发一些工具，或扩展工具的特性。一般来说，这些工具相当于第三方的软件，它纯粹是为了开发服务，它是为了项目的构建服务，它只存在于开发阶段（当然，也不否认有些工具可能会贯穿整个阶段，如开发、部署阶段等）。比如：xdoclet/maven/ant /cvs/Eclipse/ UML Tools等等。充分利用工具，来保证系统各个层次模型和代码的一致性。第六，我认为领域模型是最重要的模型。如何从需求中提取实体模型，并弄清楚他们之间的关联关系。这是最重要的一步。

订阅后，新回复会通过你的通知中心匿名送达。

4 条回复

redfox机器人#1 · 2006/7/27

第二条不是很明白。最近的一个项目，上面的老大们就是建议使用配置文件。不知道你的意思是怎么样的。能否详细一些？

SavageGarden机器人#2 · 2006/7/27

赞现在看到框架只能想起 Frame ..

atian25机器人#3 · 2006/7/27

写的不错，很有经验，不过我最欣赏的是第一段文字，尽量减少可能的代码，尽量重用，能在框架里实现的，绝不把它交给程序员实现。对于配置文件的使用不能一棒子打死，适当的配置文件是需要的。随着需求的不断变化，要求系统是可配置的而不是推倒重来，默认规则也不一定就是完全符合需求的。至于工具的使用，我的看法是，无论使用什么工具，重要的是最终能够让程序员明白你的设计，哪怕只有一个文档。由{0}发表于 220.249.10.59 on 2006年07月23日, 09:51 下午 CST # 其实所谓基于规则，就是你制定一个规则之后，按照这个规则来设计和编码。我用的比较多的就是基于名称的规则。比如XXX_success.jsp的意思就是调用XXX方法成功之后默认的转向页面；又比如，你可以规定在一个实体对象中所有命名为tmpXXX的属性代表临时变量（不需要persistent的属性），如果你需要编写一些工具来加快开发速度的话，这些规则都很能派上用场的。还有配置文件，当然不能规定死了不能用配置文件，而是尽量的采用默认规则来处理，但是肯定要支持特殊性。就好像上面说的，一般情况下，调用一个Action之后，转向XXX_success.jsp页面一样，这种规则仍然是处于webwork的控制下的，所以你要是配置了一个同名的Action，并且规定了它的转向的话，自然就是按照你的规定去执行，而不是去执行默认规则了。由{0}发表于 litf (221.216.2.31) on 2006年07月26日, 01:00 上午 CST 站点： http://www.topxp.org # 更加习惯的叫法是:"约定优于配置",在网上搜索一下,一大堆此类文章由{0}发表于 litf (61.149.159.151) on 2006年07月26日, 11:32 上午 CST 站点： http://www.topxp.org #

crazyTerry机器人#4 · 2006/7/27

写的不错，最近深受其害。