1. 它有自己独立的配置文件，该文件按照M-V的方式组织，并且为每个M和V提供逻辑命名，就象应用中经常使用的逻辑数据库连接一样，有效隔离ASP.NET逻辑与实际M和V关系，以控制反转的方式将实际M和V的执行交由框架完成。

    2. 借鉴了Java社区中MVC的实现，该框架也支持每个Controller可以支持多Action特性。虽然不是必须，但随着应用规模的扩大，1：1的Controller：Action将会使应用关联更加复杂，与其将某个业务实体或者应用的某个功能领域与多个Controller产生M：N的交互，不妨将Controller作为“挡箭牌”，由他同时管理多个Action。

    3. 随着AJAX的普及，View的概念也逐渐出现Server Side和Client Side交叉的情况，该框架提供了一个轻量的共享（Shared）UI特性，目的很简单——无论Server还是Client都可以尽量共享同一段UI代码。

    4. 照顾到中小型项目的使用要求，该框架对事务提供了简化的支持手段，从配置系统中获取的事务控制信息被“嵌”在HttpContext中，进而在Server端指导NHibernate应该对具体Action启用何种事物机制。

    5. 在对ASP.NET Request的处理上，该框架作为一个HttpHandler被配置到web.config中，对于所有的.ashx文件进行拦截（可配置为其他扩展名），根据需要调用相应的Controller和View，可将很多任务在后台直接处理掉。

    6. 为了便于开发人员使用，框架外延部分的数据访问和日志操作方面采用了NHibernate和Log4Net两个框架。

但从企业应用需要看，这个框架还有很多不足的地方。

    1. 它仅仅支持ASP.NET，而不能用于Windows Form，所有操作的隔离环境限于具体HttpContext，而没有对线程提供支持。

    2.  框架自身有些封闭，数据访问部分和事务控制部分几乎本地采用了Nhibernate，向上无法通过定制，切入Enterprise Library，向下无法让项目人员使用简洁如SqlHelper的访问机制。

    3.  其定位有些尴尬，如果确实服务于中小型应用，在Visual Studio.NET环境下，C、V混合虽然是被普遍反对的方法，但实际开发中出于进度和人员技能的限制，或多或少会出现，学习使用一个新的MVC框架似乎有些繁琐；在大规模企业应用中，这个框架扩展性又显得不够。

原文地址：http://www.infoq.com/cn/news/2007/07/pixeldragons-mvc-framework