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版面市时间**年**月 ^_^
