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/


Copyright ?999-2002 by the Apache Software Foundation. All Rights Reserved.