dogo

tdd

dogo — Tue, 04 Jan 2005 14:04:43 +0800

作者: dogo 链接：http://dogo.javaeye.com/blog/22831 发表时间: 2005年01月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

06z
TDD不是UNIT DRIVEN DEVELOPMENT，而是TEST CASE DRIVEN DELELOPMEN。TDD的流程是按照以下过程进行的：
1、USE CASE和相对应的需求表达；
2、TEST CASE；
3、从1所得到的优先次序对于2的结果进行划分，从而得到最先需要完成的TEST CASE并运行它；
4、对此TEST CASE进行设计构想；
5、完成这个设计构想；
6、用这个对应的TEST CASE（注意是一个TEST CASE系列也就是已经完成的TEST CASE系列，而不是单一的3）进行检测；
7、重复上面的步骤，并在适当的时候重构。
TDD绝对不是用TEST来驱动编码，而是用TEST来驱动分析、设计、实现的整个过程。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

lightweight architecture好处

dogo — Tue, 04 Jan 2005 13:36:02 +0800

作者: dogo 链接：http://dogo.javaeye.com/blog/22829 发表时间: 2005年01月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

gigix
lightweight architecture带来的最重要的东西，不是性能上的提升，也不是对分布式应用（尤指EJB风格）的反动。这些方面会对EJB有冲击，但不是根本性的冲击。就像你分析的，性能，EJB可以做得更好；重视本地应用，EJB可以改善；甚至AOP，EJB可以扩展出来，JBOSS就是用AOP做的。但这些只是细枝末节的修补，不是根本性的问题。

根本性的问题在于应用的独立性。我们都知道分层的架构是为了隔离变化、摆脱绑定，但是lightweight architecture让我们真正看到了一个完全无绑定的应用架构是可以实现的，至少是理论可行的。你说在“无侵入”的方面EJB和Spring是五十步与百步，从目前的效果上来说是这样，但两者的理念却是完全不同的（至少在EJB3.0之前）。朝着lightweight architecture的方向继续努力，一个完全不绑定任何框架产品的应用架构是可望而可及的。这是lightweight architecture带来的最大的理念冲击。

第一，所谓企业应用，除了联机事务处理之外，还包括联机分析处理。

第二，联机事务处理不等于EJB，就好象J2EE不等于EJB一样。J2EE提供了企业应用所必须的基础设施服务，例如事务管理、资源池缓存、分布、远程。

potian
事实上，现在所有的EJB服务基本上都有单独的产品支持，EJB1.0,2.0走的是一条all in one地解决方案，这是因为原先这些产品要么太高端，不够普及，要么相互之间的集成性不好，一旦一个系统需要所有这些服务或者这些服务的大多数，很多公司都没有这样的财力、人力作这样的集成，应该说在当时的环境下,EJB确实是一个普及和提升的过程

但随着这些服务的普及（例如TPMonitor和JTS)以及在EJB上应用这些服务的经验，新的体系结构（微核心,JMX)，新的编程范式(AOP)的推广和应用，大家又发现并不是所有的应用都需要所有的服务，就考虑是不是可以用任意拆卸的方式使用这些服务。

我想没有EJB的经验就没有今天这样的想法，这是一个螺旋上升的过程。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

struts vs webwork

dogo — Tue, 04 Jan 2005 13:22:06 +0800

作者: dogo 链接：http://dogo.javaeye.com/blog/22828 发表时间: 2005年01月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

1.使用标签。struts的自定义标签多，学习起来复杂，但同时功能强大。webwork只定义了一个webwork.tld,操作更简单。
2.有效性验证和javascript支持。struts支持客户端JavaScript与服务器端的校验。webwork的客户端校验，欠美观。具说支持javascript但是因为初学，没有试过。
3.struts和webwork都支持velocity.struts的支持是使用velocity tools,webwork则直接将velocity嵌入。比较起来webwork显示更加灵活，配置简单一些。
4.插件的支持。struts作为比较成熟的产品，拥有titles、validator插件，也可自己编写自己的插件，通过struts配置文件加载。webwork实现插件是通过定制component.xml实现。
5.显示方面。struts因为支持titles，布局更加灵活。webwork与velocity切换容易也可以定制不同的显示模板，但是定制过程繁琐一些。
6.hibernate的支持程度。struts通过过滤器和插件实现。webwork有专门的插件：org.hibernate.admin.component.HibernateSessionFactory和org.hibernate.admin.component.HibernateSession
7.模块化开发。struts支持模块化开发，支持switchAction.webwork暂时不知是否支持团队开发，支持action复用。通过定义方法。
8.显示定义formbean.struts需要显示定义 formbean或通过配置文件定义动态属性。webwork不需要定义formbean或相关属性，直接通过拦截器捕获属性。
9.资料获取。struts开源项目，支持者众多，Apache项目文档比较全。webwork相关文档和学习资料较少。

综上所述：个人认为webwork适合初学mvc模式的人，可以快速建立模型。struts为主流mvc实现，资料多，支持者多，前景看好一些。
个人观点仅供参考，进一步交流可以发邮件给我 hyluc88@yahoo.com。

这份帖子，我是不想再回，可是又不忍心让更多的朋友对WebWork存在误解。

引用:
1.使用标签。
用过WebWork标签库才知道什么叫功能强大，它可以在标签里直接调用Action方法（可以带参数的），
直接访问类的静态属性和静态方法，强大的Iterator标签库。绝对让你爽个够。（我用过Struts的标签库,JSTL,
都不能完全满足要求，直到我用了WebWork的标签库，后来才知道WebWork为什么一直保留自己的标签库。在这里也感谢王盛
将我的Groller-ww中的JSTL用WebWork标签库替换）。

引用:
2.有效性验证和javascript支持。
我首先申明WebWork是支持客户端javascript验证的，但在2.1版本中还不是很成熟，相信后面
的版本会有很好的改进。对效性验证更多看你是如何处理，我想最常用的就是自己写Javascript.如果在程序中做有效性验证，
WebWork的验证才是真正的灵活。
引用WebWork教程：
WebWork提供了在Action执行之前，对输入数据的验证功能，它使用了其核心XWork的验证框架。提供了如下功能：
1、可配置的验证文件。它的验证文件是一个独立的XML配置文件，对验证的添加、修改只需更改配置文件，无需编译任何的Class。
2、验证文件和被验证的对象完全解藕。验证对象是普通的JavaBean就可以了（可以是FormBean、域对象等），它们不需实现任何额外的方法或继承额外的类。
3、多种不同的验证方式。因为它验证功能是可以继承的，所以可以用多种不同的方式指定验证文件，比如：通过父类的Action、通过Action、通过Action的方法、通过Action所使用的对象，等等。
4、强大的表达式验证。它使用了OGNL的表达式语言，提供强大的表达式验证功能。
5、同时支持服务器端和客户端验证。

引用:
3.struts和webwork都支持velocity。
我想这就不用解释了，WebWork最好。

引用:
4.插件的支持。
Struts相关的插件确实很多，可是真正你用的又是多少？感觉就象是在打补丁。WebWork的插件应归功于它的
拦截器（AOP编程），它的很多功能框架都是通过拦截器来组装的，例如：验证、国际化、Ioc等。与其它项目的集成，
例如同Spring的完美组合都离不开拦截器的功劳。

引用:
5.显示方面。
WebWork使用强大的OGNL做为它表达式语言，它展现和存取整个对象结构的能力实在是太强了。特别是你用Hibernate
Open Session in View,这时你一定会爱死WebWork的。

引用:
6.hibernate的支持程度。
我想WebWork绝对是最好支持hibernate的J2EE Web框架。当然，如果用Spring对hibernate包装会更好。

引用:
7.模块化开发。
我的帖子：
http://forum.javaeye.com/viewtopic.php?t=6529
WebWork2真正彻底解决了这些问题.它是用package和namespace来实现真正的多模块.

package:它很类似我们Java程序的包(package),我们可以把每个模块定义成一个package,这一点与Struts的模块有些相似,但package的功能更强大,它可以继承在它上面的package,获得父package的global results、interceptor、interceptor-stack、action等所有配置.我们可以把每个package写成一个独立的配置文件,例如:module1-xwork.xml(文件的名称没有任何限制),在xwork.xml中只要通过
引用即可.
但要注意:WebWork的配置文件xwork.xml是安装文件内容顺序(从上到下)读取的,如果你的package继承了一个父package,那么这个父package必需在它之前定义.

namespace:它是package的命名空间,它用来分隔不同package定义的action，让这些action处于不同的命名空间（namespaces）。
这样，我们不同的package可以有相同的action命名，因为可以通过命名空间来区分。如果不指定namespace，默认的是空字符串。
命名空间也可以被用在安全控制方面，它可以根据不同的命名空间指定不同的访问权限。
...................................

引用:
8.显示定义formbean。
Struts的FormBean是公认的败笔，WebWork会让你爽个够。

引用:
9.资料获取。
struts确实占优势。

引用:
综上所述：
WebWork简单、灵活、高效。Struts笨重、复杂、不够灵活。如果想更好的提供开发效率，WebWork是你最好的选择，
项目越大越负责越能体现WebWork的优势。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

potian的工具箱

dogo — Thu, 30 Dec 2004 18:31:35 +0800

作者: dogo 链接：http://dogo.javaeye.com/blog/22809 发表时间: 2004年12月30日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

准备篇

1。白板（白板笔）。
1)需求阶段和客户讨论问题时分析、设计、客户在这里自由交流大家对问题的看法
2)在项目分析和设计阶段用来进行头脑风暴，是设计的最重要的工具。白板上画的可以是UML图，但也可以是项目团队能够理解的任意图形，或者就是简单的线条、图形都可以
3)无处不在的讨论，任何时候对需求的理解和对设计的讨论都在白板上进行

一般公司里面经常会出现白板笔太久没用水用光的时候，所以我一般都要提醒后勤人员买好充足的笔，用完笔以后要盖好盖子。

2卡片（和图钉）
1） CRC是除了白板以外第二重要的设计工具，这种卡片在中国很难买到，所以一般用文摘卡代替，CRC的重要作用在于可以进行角色扮演，验证设计的准确性。CRC的前面分别写责任和协作，背面可以进行备注
2）用户故事卡，我回去定制一个泥印，直接盖在空白的用户故事卡上，这个卡片在需求阶段可以任意传递、撕毁、重写、合、分裂，卡上有故事卡编号、优先级、风险评估和当前的迭代序号，用户故事卡订在一个大家都能看到的离开发位置较远的墙壁上
3）任务卡，任务卡从故事卡分裂而来，用图钉钉在开发员的电脑旁边
4）编码卡，主要纪录需要实现的测试，需要注意的事项，等等，开发人员不断增加条目、划去条目，是对一个人物而言的备忘录和todolist

3．大坐标纸（长的直尺、各种颜色的笔）

我通常会在项目的进行过程中记录各种度量，这包括有效代码增长率、测试代码增长率、功能测试通过率、故事卡完成率、测试覆盖率（具体工具在后面介绍），悬挂在比较高的位置，大家一眼能够看到的地方

另外每个迭代的每个理想天都会检查每个人任务完成的情况，延迟、提前、原因、重新估计时间、剩余实践，根据不同情况用不同的颜色表达，画在一张大白纸上，不够的话可以慢慢接长，贴在显而易见的墙壁上

4、小桌子（香烟、绿茶、咖啡或水果）
工作一段时间，2个小时左右，开发人员可以三两成群地在小桌子（或者是吸烟区）旁边抽烟、喝茶、咖啡或者水果，交流相互的心得、讲讲笑话、谈谈碰到的问题。很多问题就在这里面谈出来、解决、得到线索等等，团队的气氛经常就是在这个时候变得慢慢融洽。

本来我有些照片，但现在一下子找不到了
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

组件复用

dogo — Thu, 30 Dec 2004 12:28:29 +0800

作者: dogo 链接：http://dogo.javaeye.com/blog/22803 发表时间: 2004年12月30日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

关于复用性，根本就不需要讨论，限制越少，复用性就越高。不管怎样去讨论问题,EJB永远不可能比一个普通的JavaBean更可以复用。也就是说，如果Spring是谎言，那么EJB就是扯淡了。

如果你的程序模块或者框架真正被n个人或者n各不同的项目组复用过，你就会知道不对体系结构作任何限制是多么多么的重要。如果你真正编过一些复杂的框架，你就会知道天马行空、不受拘束的对象建模和实现是多么多么的必需。

有一个不是直接有关的话题。我对目前有多少可以黑箱重用的业务组件持非常怀疑的态度，相反，可重要的工具箱，可白箱复用的框架是我认为目前最现实，也是提高生产效率最有效的途径。这也是我从5年来对组件认识的一个变迁。我认为软件工业现在还只是发展到这个阶段，甚至在一定范围内只能发展到这个阶段，因为软件是软的，一个在非常大范围内可以黑箱重用的组件（例如CPU)会变得非常复杂，而不能像CPU一样只需要几个简单的接口标准就可以插到任何主板上。

我也不理解什么容器的复用性比组件的复用性更重要这样的结论。

如果不要部署就可以实现需要你所认为最最牛的部署的人的话，我为什么还需要部署。

我认为讨论谁好谁坏没有任何意义，有意义的是讨论什么情况下适合什么情况下不适合?

接下去就是讨论你这个项目该不该用EJB，我的结论是
只有在需要分布式业务处理的系统中，EJB才存在着价值，因为其他的东东（例如分布式事务、ORM）我现在已经直接可以使用非常成熟的单独产品了，唯独在分布式Java对象这一块上，EJB还是具有它不可取代的优势。所以要用EJB也只需要用它的SessionBean即可。

越是复杂的技术维护成本越高，不必要的复杂性更是会害死人。

面向对象为什么可以战胜面向过程，现在完全占据了统治地位，就是因为面向对象大幅度降低了软件开发、测试和维护的成本。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐