|
Jakarta main
Avalon main
About
章节
原文链接
Printer Friendly
中文译者
|
Avalon经受了时间的考验,可以供您使用。本部分提供的证据可以帮助说服您自己和其它人,使用一个成熟的框架比自己创建一个要好。
您可能已经被说服了,但需要一些帮助来说服您的同事,让他们相信Avalon是正确的选择。 也许您也需要说服您自己。
不管怎样,本章将帮助您整理思路,并提供一些有说服力的证据。 我们需要与对开放源代码模式的(Fear, Uncertainty, and Doubt
,FUD)作斗争。 关于开放源代码的有效性的证据,我推荐您阅读Eric S. Raymond对这一主题的优秀论述N400017.
不论您对他所持观点的看法如何,他写的文章汇编成的书The Cathedral and the Bazaar
将提供使人从总体上接受开放源代码的信息。
Avalon能工作 |
我们的底线是Avalon完成了它最初设计时要达到的目标。
Avalon没有引入新的概念和思想,而是使用了一些经受时间考验的概念,并将它们规范化。
影响Avalon设计的最新的概念是分离考虑(Separation of Concerns)模式,它大约是在1995提出的。即使在那时候,
分离考虑也是一种系统分析技术的规范化方法。
Avalon的用户群数以百计。 一些项目如Apache Cocoon, Apache JAMES,
和Jesktop是建立在Avalon之上的。这些项目的开发者是Avalon Framework的用户。
因为Avalon有如此众多的用户,它得到了很好的测试。
由最优秀的人设计 |
Avalon的作者认识到,我们不是服务器端计算的唯一一群专家。
我们使用了来自其它人的研究的概念和想法。
我们响应来自用户的反馈。Avalon不仅仅是由前面介绍的5个开发者设计的,他们带来的是反向控制、分离考虑和面向组件编程的思想,并设计了它。
开放源代码的优秀之处在于,得到的结果是最佳的思想和最佳的代码的融合。
Avalon经过一了些测试想法的阶段并拒绝了一些想法,因为还有更好的解决方案。
您可以利用Avalon开发小组所获得的知识,并在您自己的系统中运用。
您可以在自己的项目中使用Excalibur中预先定义好的组件,它们经过了测试,可以在重负载下运行无误。 |
兼容性的许可证 |
Apache Software License
(ASL)可以兼容其它任何已知的许可证。 已知的最大例外是GNU Public License (GPL)
和Lesser GNU Public License (LGPL).
重要的是ASL对合作开发相当友好,如果您不想的话,也不会强迫您发布源代码。 Apache Software
Foundation名下的德高望众的HTTP服务器用的是相同的许可证。 |
集群式的研发 |
大多数的Avalon用户以某种方式做出他们的贡献。这把开发,调试和文档的工作量分散到了一些用户身上。
这也表明Avalon的代码经过了更广泛的对等复查,这在公司开发中是不可能做到的。 而且,Avalon的用户支持Avalon。
尽管开放源代码的项目通常没有一个帮助平台或电话支持热钱,但是我们有一个邮件列表。
您的许多问题可以通过邮件列表得到很快的回答,比一些支持热线还要快。 |
简化的分析和设计 |
基于Avalon开发有助于开发者达到一种精神状态。
在这种精神状态下,开发者的工作集中在如何发现组件和服务上。
既然关于组件和服务的生存期的细节问题都已得到分析和设计,开发者只需选择他们需要的就行了。
需要重点指出的是,Avalon的开始并不是取代了传统的面向对象分析和设计,而是对它进行了增强。
您还是使用以前所用的技术,只不过现在您有了一组工具,能更快地实现您的设计。 |
|
Avalon已经就绪 |
Avalon Framework, Avalon Excalibur, 和 Avalon
LogKit已经准备好让您使用了。它们已经成熟,只会变得越来越好。 尽管Avalon Phoenix和Avalon
Cornerstone正在紧锣密鼓地开发,但您在它们基础上写的代码将来只需做些不重要的改动就能工作。 |
N400017)
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
|