Nvelocity及MonoRail比较研究

因为在琢磨MonoRail的使用,我尝试一些在ASPNET应用中常用的场景。

先说一下感触,的确,MonoRail使用模版来展示数据,可以强制开发者将显示逻辑与控制模型比较清晰的分离,不过也有一些问题。首先缺少一个可视化的开发工具,这只是一个比较次要的问题。假设团队中某些成员没有基本Html的知识,那只能说他需要补习。MonoRail的一些功能有些我还没去测试完整,另外对Java下使用VeloCity在真实世界中的开发资料也不了解。总之,我对Nvelocity是满意的。但缺乏足够的证据去说服别人使用它。说说它的好处,在Web页面内引用CSS或者javaScript 文件时,如果大部分页面都作为一个共同模版的ChildComent,通常是使用Default.vm作为一个Layouts的应用,从一个AbstractController继承而来。那么你修改一个Default.vm文件就能更新所有继承*.vm文件。这的确是一个非常方便的功能。同理,你可以在这里做不少的分支,不同的模块可以从不同的模版得到好处。

 

Filter的使用,这应该说是AOP的一个应用。对减少编码量和集中控制权限很有益处。我是一个懒人,所以我不想放弃这个框架带来的便利。但使用一个开源框架,应该比较深入它的前途。撇开升级不谈,我想说的给人的信服度。当然这也是我没有详细深入它的缘故,我不敢拍胸脯说,没问题!虽然我这些天用它实现了一个比较基本的Demo,常规应用是没有问题的。所以我更想找到别人对它的认可。对于MonoRail页面导航及数据绑定的能力我比较确认,但对于ASPNET 服务器控件的兼容(有些便利的应用是使用一些服务控件,比如一个html编辑器)。另外对于复杂界面的控件显示状态控制,对于服务器端控件,你可以方便的设定它的显示属性。最后这点,我也比较矛盾。这些显示逻辑其实也是和业务逻辑联系在一起,是否可以通过设计多个View来显示,还是在一个View按照逻辑进行显示,从维护的角度,后者是清晰的,也许这就是应该规范或者改进的地方?但维护较多的View使用UserControl不是更好吗?MonoRailViewControl还没来的及仔细测试,也许它就是解决方法。???

 

Google上搜索NVelocity的资料,从TheServerSide看到一个文章,里面是推崇MonoRail的。另外就是看到MonoRail的作者和一些鬼佬的讨论,具体地址给忘记了,懒得再搜索了。在他们讨论NVelocity时,提到它是一个停滞很久的项目。之前因为Nvelocity的版本比较低,我也有此担心,没想到的确是停滞了很久。现在既然要去用它,对于这样一个停滞项目,信心备受打击。在没有.vm编辑器时,可以说是个小问题,现在的状况更糟糕了,不能忽视。除非我有勇气去在需要的时候去维护Nvelocity的代码。这的确是个问题!有人使用MonoRail的模版,而不使用Nvelocity,对于这样的情况,有人反对,因为那是一种不单纯。可现在的情况,舍弃Nvelocity,而选择一个更靠近M$的方案会更有可用性吧。除了我改造Nvelocity的能力,否则我不想冒这个风险。而另一个Boo的方案,更是文档不明细。Rod 也说开源框架的选择要慎重,其中一些指标,包含了开源团队的力量、更新频率、Bug修复周期、文档丰富程度、用户群大小等。

 

之后一天,我与一个开发经验很丰富的朋友谈到开源,他认为开源是垃圾。之前也有网友抱怨开源代码的零乱,我以为那只是部分。现在不得不考虑,他的意见我想还是认真考虑一下。而我提到EnterPrise Library,我和他的意见到比较一致。M$的可信度高于普通的开源代码。之前也用过以EnterPrise Library为基础的一个三层快速开发模版,效果还不错。的确替我做了很多繁琐的工作,如果说那些代码里面有很多是过度工程的话,那也是模版的责任。EnterPrise Library还是很强的。反过来说,公司里的同事也会对EnterPrise Library持有比较肯定的态度,这么说,我要去琢磨EnterPrise Library了?我对它的配置复杂比较反感。今天又大致端详了它的代码,质量的确超越了开源代码。

 

设想一下,使用ASPNET作为显示,使用绑定来替代MonoRailDataBind,使用UserControl来及Hmtl框架来替代MonoRailLayouts。不过网页导航以及页面之间的数据传递又要回到之前的模式,也许我该仔细看下MonoRail里对ASPNET模版的应用。数据访问层等基础框架使用EnterPrise Library来做,这样基本上兼顾了几个方面。同学们的学习曲线也不会那么陡峭,更让我觉得安心的是,在Ghj谈到CSDN论坛改造时候,在一个性能需求很强烈的项目中,使用EnterPrise Library,而不是ORM产品,应该有他的理由。如果能避免弯路,我宁肯听信别人的经验。真正做一个企业级的成功应用还有好多东西要学习。


今天仔细看了关于MonoRail 对于ASPx的支持,应该说这2个东西很难融合在一起。

查了下Nvelocity的代码,粗略估计下,去维护它花些时间也不是不可能;翻看历史的Bug纪录,Bug量比较小,又不想放弃Nveloctiy了。
这真是个矛盾!暂时做项目的话,还是用回Aspx了,再深入Nvelocity的代码看看了。

 

方法上,一是OOP,一是数据并发及数据访问模式。???

实践上,一是较高的测试覆盖率,一是面向对象的思考和设计过程。

那么相面就剩下2个事情需要着重琢磨一下,用好EnterPrise Library ,研究Nvelocity的代码
 

你可能感兴趣的:(.NET,library,框架,velocity,javascript,测试,服务器)