Vivo Cielo Studio Proposal
HTML、JavaScript、CSS、C#、SQL都是编程语言,可把几个东西结合起来开发一个项目却那么多事情,开发的世界里脏、乱、差
ASP、ASP.NET、MonoRail、Sprint.Net、ASP.NET MVC、NHibernate、iBatis、LINQ to ...、ADO.NET Entity Framework,还有客户端的Ajax、FLEX、Silverlight等RIA技术,技术思想在快速发展,对好的开发人员要求越来越高,可项目的问题不见得越来越少
问题关键在什么地方呢,是对上下文环境Context的处理。Context有两大鸿沟:数据库与程序运行环境之间,程序运行环境与客户端之间,即Database<->Domain、Domain<->Web之间
Ruby on Rails是个比较酷的名字,它最大的优点是在开发语言这个层面将3个上下文紧密结合起来。对比其它一些解决方案看看:
1. ASP.NET
客户端WebForm、服务器端Code Behind,宏观上看是非常好的解决方案,因为很大程度上为开发者抹平了Web Client与Web Server之间的沟渠
缺点是一方面微软做事比较粗糙。在Web Form上拖放Connection、DataGrid控件,设置属性然后页面就完成了,这个方法太简单。Code Behind再往后怎么走,多年以来一直没有提供好的解决方案,开发者很难自己摸索出一个优秀的开发模型。Enterprise Library只是几个Utilities而已,离构建一个完善的开发模型解决方案距离太远。现在LINQ to ...出来弥补这一块,但离ASP.NET最初推出已经7、8年时间了
另一方面我想是开放性和推广方面,ViewState PostBack机制运用于整个页面太笨重;Client ID等不少HTML属性由框架操控,剥夺了开发者一定的控制权;加之Page Life Cycle、安全控制策略等一系列的重型机制,Web Control的开发也复杂。也就是说ASP.NET内部处理太庞杂,开发者能够全面了解、对这个过程能够切入控制的力度非常有限。如果开源,开发者社区自然能够解决这个问题,或者微软采取出书、MSDN开一系列文章或专开一个频道,详细完整的讲解整个机制并接收社区的反馈进行完善,Web Form的发展或者整个.NET开发状况不会是现在这个样子。RIA概念造成开发过程需要对客户端有绝对的控制权,搜索引擎优化、服务器端开发模型的发展等对控制器的接管要求也越来越强列,因此现在出来ASP.NET MVC,IIS7的Filters Pipeline更灵活,看起来更象是形式所迫被动的开发这些框架满足当前的要求
2. MonoRail
整合了NHibernate,这是MonoRail衔接Database与Domain的解决方案;ViewEngine有多种选择,开发者对Template有了选择性,也能完全控制View的输出
另一条既是优点也是缺点。Hibernate完全是Java社区的思想,遵循JCP等规范,对设计要求比较很高,对例外情况不鼓励,例外情况的解决方案也很简单(确实有足够的理由这样做),我想这是MonoRail在.Net社区的普及中一个很大的障碍。ASP.NET MVC这一王牌军上来,真的不知道MonoRail后面的路是否能走好。但这也是NHibernate、MonoRail的优点,因为这套领域建模的思想是无数项目、无数优秀开发者思想的结晶,拥有完整的思想体系和众多的分支,以及其它框架、工具的支持大体都是遵循这个思想体系,在自己的范围内把特定问题更好的解决掉,只是开发者要透彻理解、掌握这个体系很不容易,需要大量实际项目经验的支撑以及投入精力不断思考研究。但相比微软以前的做法,除了Web Cast上拖拖拉拉或者直接写SQL的示例,以及几个Utilities库之外,剩余事情开发者怎么解决就不管了,还是要好多了。RoR的Convention Over Configuration也是对这个问题的一种解决方案,技术、思想等相关知识爆炸性增长,当一个项目使用N个非常优秀的框架仍然无法覆盖主要设计时,开发项目如何掌控?
与RoR相比,MonoRail在几个Context之间的交互还是逊色一截
所以,我得自己开发一个了
可以借鉴参考的概念和已有框架结构:RoR, Web Form, MDA, MVC, COM组件模型, SharpDevelop Add-In结构(或者FireFox、jQuery的扩展性结构), REST, web-based command line, MFC文档视图架构, jQuery, MonoRail, NHibernate, LINQ to SQL等
ASP、ASP.NET、MonoRail、Sprint.Net、ASP.NET MVC、NHibernate、iBatis、LINQ to ...、ADO.NET Entity Framework,还有客户端的Ajax、FLEX、Silverlight等RIA技术,技术思想在快速发展,对好的开发人员要求越来越高,可项目的问题不见得越来越少
问题关键在什么地方呢,是对上下文环境Context的处理。Context有两大鸿沟:数据库与程序运行环境之间,程序运行环境与客户端之间,即Database<->Domain、Domain<->Web之间
Ruby on Rails是个比较酷的名字,它最大的优点是在开发语言这个层面将3个上下文紧密结合起来。对比其它一些解决方案看看:
1. ASP.NET
客户端WebForm、服务器端Code Behind,宏观上看是非常好的解决方案,因为很大程度上为开发者抹平了Web Client与Web Server之间的沟渠
缺点是一方面微软做事比较粗糙。在Web Form上拖放Connection、DataGrid控件,设置属性然后页面就完成了,这个方法太简单。Code Behind再往后怎么走,多年以来一直没有提供好的解决方案,开发者很难自己摸索出一个优秀的开发模型。Enterprise Library只是几个Utilities而已,离构建一个完善的开发模型解决方案距离太远。现在LINQ to ...出来弥补这一块,但离ASP.NET最初推出已经7、8年时间了
另一方面我想是开放性和推广方面,ViewState PostBack机制运用于整个页面太笨重;Client ID等不少HTML属性由框架操控,剥夺了开发者一定的控制权;加之Page Life Cycle、安全控制策略等一系列的重型机制,Web Control的开发也复杂。也就是说ASP.NET内部处理太庞杂,开发者能够全面了解、对这个过程能够切入控制的力度非常有限。如果开源,开发者社区自然能够解决这个问题,或者微软采取出书、MSDN开一系列文章或专开一个频道,详细完整的讲解整个机制并接收社区的反馈进行完善,Web Form的发展或者整个.NET开发状况不会是现在这个样子。RIA概念造成开发过程需要对客户端有绝对的控制权,搜索引擎优化、服务器端开发模型的发展等对控制器的接管要求也越来越强列,因此现在出来ASP.NET MVC,IIS7的Filters Pipeline更灵活,看起来更象是形式所迫被动的开发这些框架满足当前的要求
2. MonoRail
整合了NHibernate,这是MonoRail衔接Database与Domain的解决方案;ViewEngine有多种选择,开发者对Template有了选择性,也能完全控制View的输出
另一条既是优点也是缺点。Hibernate完全是Java社区的思想,遵循JCP等规范,对设计要求比较很高,对例外情况不鼓励,例外情况的解决方案也很简单(确实有足够的理由这样做),我想这是MonoRail在.Net社区的普及中一个很大的障碍。ASP.NET MVC这一王牌军上来,真的不知道MonoRail后面的路是否能走好。但这也是NHibernate、MonoRail的优点,因为这套领域建模的思想是无数项目、无数优秀开发者思想的结晶,拥有完整的思想体系和众多的分支,以及其它框架、工具的支持大体都是遵循这个思想体系,在自己的范围内把特定问题更好的解决掉,只是开发者要透彻理解、掌握这个体系很不容易,需要大量实际项目经验的支撑以及投入精力不断思考研究。但相比微软以前的做法,除了Web Cast上拖拖拉拉或者直接写SQL的示例,以及几个Utilities库之外,剩余事情开发者怎么解决就不管了,还是要好多了。RoR的Convention Over Configuration也是对这个问题的一种解决方案,技术、思想等相关知识爆炸性增长,当一个项目使用N个非常优秀的框架仍然无法覆盖主要设计时,开发项目如何掌控?
与RoR相比,MonoRail在几个Context之间的交互还是逊色一截
开发模式整体流畅,开发工作便利,但不丧失灵活性
对于后端,ORM是必须的,需要具备NHibernate大部分主要特性,但不必象NHibernate那样坚持以良好的模型设计为基础,并且是必要前提。最大化生产力也是非常重要的一个因素,考虑生产力的因素与理想化的设计思想总是存在一定差距。很多项目时间紧迫,没有充足的时间一次性作出完善的设计;想象中的完善设计还不一定是客户真正需要的东西;在迭代过程中第1、2轮重点关注主要部分、核心流程,并且有与最终客户交互确认的因素,以及部分初期无法最终确定是否为合理、优化的设计方案。应该Rails起来,敏捷起来
对于前端,MVC的确需要分离,但仍得多考虑生产力的问题,分离之后得保证开发流程仍然顺畅。在Web上V和C相隔十万八千里,是最难摆弄的部分。MVC 2模式应当要尝试作出改变了,也许还是MVC更适合
模板引擎这种做法,Web Server与Client之间的这条沟终究是很难填平的,包括目前各种Web MVC框架和RoR在内都是这样。"世界是平的",这就是Vivo Cielo Studio框架的目标
其实Rails的做法也并不新鲜,只是将ActiveRecord、模板引擎等集成到语言平台上,在同一个开发环境上下文中方便的完成各个方面的事情,确实是件愉快的工作。RoR对整个开发模式而言是流畅了,它将生产力和设计结构性兼顾起来,但RIA的趋势下客户端的Rich Control,以及如何将HTML组件化,更好的重用HTML组件等,估计RoR还是很难解决的
可以借鉴参考的概念和已有框架结构:RoR, Web Form, MDA, MVC, COM组件模型, SharpDevelop Add-In结构(或者FireFox、jQuery的扩展性结构), REST, web-based command line, MFC文档视图架构, jQuery, MonoRail, NHibernate, LINQ to SQL等
Java在这方面尝试的项目很多,各自采用了不同的方法,例如JBlooming、Helma等
项目内部代码Vivo Cielo Studio,整体粗略的方案已经成型,Alpha版面市时间**年**月 ^_^