在我看来,在这个线程中大家都在谈论这种框架的名字。我现在称它们为类似RAILS的框架:这些框架通过协调其他现有框架来提高生产力,以解决大多数Web应用程序的基本需求,但同时又对开发人员隐藏了所有复杂性。
基本需求是指实现持久性提供程序,依赖检查容器,日志记录工具,MVC平台,HTML模板引擎,带有CSS预设的网站模板入门工具包,安全框架以及一些用于AJAX功能的Javascript库和其他很酷的东西。类似RAILS的框架在域模型(系统实体及其属性)的基础上协调所有这些框架和工具。
多亏了Convention-over-Configuration原则,这些框架无需定义许多通常由其协调的框架(例如Spring,Spring MVC,Hibernate,Log4J等)所需的配置文件,假设默认情况下基于命名进行配置,包含在相同类定义中的结构和元数据。
由于这些框架使用了动态语言(例如Ruby,Groovy,Python,Clojure等),除了SpringRoo通过使用AspectJ在Java中实现动态行为之外,属于该框架的功能得以扩展和扩展。开发人员以统一且优雅的方式使用开发人员,以使他/她仅了解底层技术。
最后,由于使用了Scaffold技术,因此可以在开发人员定义的每个域对象上自动为主要功能(CRUD)生成单元测试,集成测试,控制器和视图。
在.NET世界中,按照之前的所有定义,尚未开发出任何东西。但是没有什么可以阻止这种情况很快发生。.NET世界中已经有许多出色的框架,工具和库,可以通过为CLR制作的类似于RAILS的新框架进行编排。有Unity,Spring.NET和Castle Windsor等用于依赖检查的需求。实体框架4,NHibernate和iBatis.NET都是非常好的.NET持久性提供程序。除了传统的ASP.NET,ASP.NET MVC强烈支持各种模板引擎。
即使没有人能够使用DLR语言构建这种框架,任何有足够能力的人都可以遵循SpringSource路径,并使用某种静态语言(例如F#,C#或VB.NET)来实现类似RAILS的框架,并使用Aspect面向容器(如AspectSharp或Gripper-LOOM.NET)以获取动态行为。
我很想知道任何人尝试在.NET中开发此类框架。