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不是更好吗？MonoRail的ViewControl还没来的及仔细测试，也许它就是解决方法。？？？

 

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

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

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

 

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

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

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