Z
zbird
Unregistered / Unconfirmed
GUEST, unregistred user!
无聊时在自己blog上YY的，大家将就着看吧。
//---------
引言
最近的DFW上全部都是2006，似乎有些过于沉闷。口水帖子虽然缺乏建设性，但适量的口水，多少还能给这个世界带来一些新鲜空气的。
JAVA，为什么又是JAVA不是PHP、ASP。因为JAVA红，俗话说人红事多。现在的新人为了吸引眼球总得拉个大腕作幌子，就象前一阵子天涯上的猫人。JAVA，因为JAVA红。
又是Ruby，又在CSDN上看到关于Ruby的帖子。我一直都承认我对脚本语言是存在偏见的，而且固执己见。
Ruby可能流行吗？可能。 Ruby能挑战Java吗？表示怀疑。
JAVA其实可以更简单，JAVA目前的这个局面更多的是因为厂商利益。在Ruby开始威胁到JAVA的时候，JAVA可以变得简单起来。而且在提供方便性将在一定程度的限制功能。有时候，一个东西完善的过程，也是一个复杂化的过程。我觉得Ruby应当是这样的一个东西。最重要的一点，Ruby的定位和JAVA不一样。JAVA定位相对比较高一些。要抢底盘也是抢PHP的，JAVA受到的威胁相对要小一些。
又想到了APPFUSE。APPFUSE一个不错的集成框架。而且自身带的代码生成器使用也很方便。只要写完VO并为VO写上XDoclet的标注后，直接运行ant命令就可以自动完成数据库的部署并将包括表示层的所有相关代码生成。完全一站式的代码生成。
既然APPFUSE如此完美为什么没有广泛的流行起来？
Appfuse基于脚本的代码生成，对细节封装得不够（或者说隐藏吧）。虽然完全按照Appfuse的预定流程来作很方便，可以实现对开发细节的隐藏，但在大多数情况下大家都需要对框架进行扩展来实现自己的需求。既然要扩展，你就必须要了解框架的具体实现细节，而appfuse使用的技术N多。如果要熟悉还是得花些时间的。
说到这里可能很多人要说到JAVA的复杂性了。对，JAVA很复杂，但同样也可以很简单。虽然技术多，但并不不代表你要了解的东西要很多。技术是用来简化开发的，如果一个新技术的出现反而使开发复杂化了，那这个技术是不值得采用的。在appfuse中采用的新技术都是有其价值的。appfuse缺的是文档。不光是appfuse的文档，还有appfuse所采用的技术的相关文档。这些文档不需要很复杂，只要那么一两页纸告诉框架的使用者这些技术是用来作什么的。对于这些技术只介绍必要部分，暂时用不着的都不用讲，尽量简化（隐藏）框架的复杂性。
appfuse中大量的使用了ant脚本来实现自动化。但也正是由于过于依赖这些脚本，导致框架和IDE的结合不是很好。到目前我还不是很清楚怎么用IDE对appfuse进行调试。虽然这很可能是因为我对appfuse的研究不够，但对于一个以方便为目的的框架，不应该将和IDE的整合交给框架的使用者去作。
还有就是appfuse的那个权限系统实在是让人有些不爽。不同系统对权限系统的要求都不一样。权限系统这一块本该是可以灵活配置的，可以很方便的从系统中移除，自己实现。但appfuse的权限系统和框架绑这么紧，要分出去多少还得话些时间。
说了这么多appfuse的“坏话”，不过还是希望appfuse能快速成熟起来。对appfuse来说功能不是问题，最大的问题是人性化，JAVA也是这样。
PS：
最近看到appfuse有个代码生成器的子项目appfuse generator。用Velocity替代xdoclet作为模版生成引擎。刚开始研究，还不清楚和appfuse里面集成的代码生成器相比有什么优势。
新版本的appfuse集成了一个缓存系统，有时间可以研究一下。
//---------
引言
最近的DFW上全部都是2006，似乎有些过于沉闷。口水帖子虽然缺乏建设性，但适量的口水，多少还能给这个世界带来一些新鲜空气的。
Ruby vs Java? and appfuse
《新技术倍出 谁最可能挑战Java开发优势》，感觉挺恶俗的一个名字。不过既然要圈钱就得制造点事端，制造点热点。一个东西不管好不好，有人理就是好事。JAVA，为什么又是JAVA不是PHP、ASP。因为JAVA红，俗话说人红事多。现在的新人为了吸引眼球总得拉个大腕作幌子，就象前一阵子天涯上的猫人。JAVA，因为JAVA红。
又是Ruby，又在CSDN上看到关于Ruby的帖子。我一直都承认我对脚本语言是存在偏见的，而且固执己见。
Ruby可能流行吗？可能。 Ruby能挑战Java吗？表示怀疑。
JAVA其实可以更简单，JAVA目前的这个局面更多的是因为厂商利益。在Ruby开始威胁到JAVA的时候，JAVA可以变得简单起来。而且在提供方便性将在一定程度的限制功能。有时候，一个东西完善的过程，也是一个复杂化的过程。我觉得Ruby应当是这样的一个东西。最重要的一点，Ruby的定位和JAVA不一样。JAVA定位相对比较高一些。要抢底盘也是抢PHP的，JAVA受到的威胁相对要小一些。
又想到了APPFUSE。APPFUSE一个不错的集成框架。而且自身带的代码生成器使用也很方便。只要写完VO并为VO写上XDoclet的标注后，直接运行ant命令就可以自动完成数据库的部署并将包括表示层的所有相关代码生成。完全一站式的代码生成。
既然APPFUSE如此完美为什么没有广泛的流行起来？
Appfuse基于脚本的代码生成，对细节封装得不够（或者说隐藏吧）。虽然完全按照Appfuse的预定流程来作很方便，可以实现对开发细节的隐藏，但在大多数情况下大家都需要对框架进行扩展来实现自己的需求。既然要扩展，你就必须要了解框架的具体实现细节，而appfuse使用的技术N多。如果要熟悉还是得花些时间的。
说到这里可能很多人要说到JAVA的复杂性了。对，JAVA很复杂，但同样也可以很简单。虽然技术多，但并不不代表你要了解的东西要很多。技术是用来简化开发的，如果一个新技术的出现反而使开发复杂化了，那这个技术是不值得采用的。在appfuse中采用的新技术都是有其价值的。appfuse缺的是文档。不光是appfuse的文档，还有appfuse所采用的技术的相关文档。这些文档不需要很复杂，只要那么一两页纸告诉框架的使用者这些技术是用来作什么的。对于这些技术只介绍必要部分，暂时用不着的都不用讲，尽量简化（隐藏）框架的复杂性。
appfuse中大量的使用了ant脚本来实现自动化。但也正是由于过于依赖这些脚本，导致框架和IDE的结合不是很好。到目前我还不是很清楚怎么用IDE对appfuse进行调试。虽然这很可能是因为我对appfuse的研究不够，但对于一个以方便为目的的框架，不应该将和IDE的整合交给框架的使用者去作。
还有就是appfuse的那个权限系统实在是让人有些不爽。不同系统对权限系统的要求都不一样。权限系统这一块本该是可以灵活配置的，可以很方便的从系统中移除，自己实现。但appfuse的权限系统和框架绑这么紧，要分出去多少还得话些时间。
说了这么多appfuse的“坏话”，不过还是希望appfuse能快速成熟起来。对appfuse来说功能不是问题，最大的问题是人性化，JAVA也是这样。
PS：
最近看到appfuse有个代码生成器的子项目appfuse generator。用Velocity替代xdoclet作为模版生成引擎。刚开始研究，还不清楚和appfuse里面集成的代码生成器相比有什么优势。
新版本的appfuse集成了一个缓存系统，有时间可以研究一下。
