它有自己独立的配置文件，该文件按照M-V的方式组织，并且为每个M和V提供逻辑命名，就象应用中经常使用的逻辑数据库连接一样，有效隔离ASP.NET逻辑与实际M和V关系，以控制反转的方式将实际M和V的执行交由框架完成。
借鉴了Java社区中MVC的实现，该框架也支持每个Controller可以支持多Action特性。虽然不是必须，但随着应用规模的扩大，1：1的Controller：Action将会使应用关联更加复杂，与其将某个业务实体或者应用的某个功能领域与多个Controller产生M：N的交互，不妨将Controller作为“挡箭牌”，由他同时管理多个Action。
随着AJAX的普及，View的概念也逐渐出现Server Side和Client Side交叉的情况，该框架提供了一个轻量的共享(Shared)UI特性，目的很简单——无论Server还是Client都可以尽量共享同一段UI代码。
照顾到中小型项目的使用要求，该框架对事务提供了简化的支持手段，从配置系统中获取的事务控制信息被“嵌”在HttpContext中，进而在Server端指导NHibernate应该对具体Action启用何种事物机制。
在对ASP.NET Request的处理上，该框架作为一个HttpHandler被配置到web.config中，对于所有的.ashx文件进行拦截(可配置为其他扩展名)，根据需要调用相应的Controller和View，可将很多任务在后台直接处理掉。
为了便于开发人员使用，框架外延部分的数据访问和日志操作方面采用了NHibernate和Log4Net两个框架。
但从企业应用需要看，这个框架还有很多不足的地方。
它仅仅支持ASP.NET，而不能用于Windows Form，所有操作的隔离环境限于具体HttpContext，而没有对线程提供支持。
框架自身有些封闭，数据访问部分和事务控制部分几乎本地采用了Nhibernate，向上无法通过定制，切入Enterprise Library，向下无法让项目人员使用简洁如SqlHelper的访问机制。
其定位有些尴尬，如果确实服务于中小型应用，在Visual Studio.NET环境下，C、V混合虽然是被普遍反对的方法，但实际开发中出于进度和人员技能的限制，或多或少会出现，学习使用一个新的MVC框架似乎有些繁琐;在大规模企业应用中，这个框架扩展性又显得不够。
尽管如此，如果项目已经选择NHibernate进行ASP.NET项目开发的话，该框架可以作为一个不错调度机制集成。经过它的“梳理”，在项目页面的不断修改和充实情况下，依然可以在代码外围——配置文件中管理他们，尤其是Controller可以根据需要同时激活多个Action。另外，相对“庞大”的UIP而言，PixelDragonsMVC.NET专注而且简洁很多，学习门槛也非常低。
