虽然我不喜欢讨论太多理论概念上的东西，但各位“砖家”还是提出了很多非常有针对性的意见，望此帖不要成为口水战才好....现答疑如下（有很多个人理解，不一定正确）：
砖家意见请参见：Asp.Net大型项目实践系列导航
为什么选择NHibernate
理由1：对象关系映射技术（ORM）的最主要目的是为了解决关系型数据库与面向对象编程技术不匹配的阻抗问题，何为阻抗？通俗的说面向对象的类往往都存在继承和类间关系与数据库的表不是一一对应的，ORM技术可能主要是想解决这个问题。这里需要说一下好多同学和砖家在用ORM的时候还是喜欢先建表，再工具生成和表字段一一对应的所谓实体，个人认为这不是O->R M,而是R->O M,实际上这种做法完全没有体现ORM的最关键思想，还是以前的“表驱动”（通俗解释：先设计表）而非“业务领域驱动”（通俗解释：先设计真正面向对象的业务实体）。因为我的系统业务比较复杂多变，我希望我能尽可能的随心所欲的按照面向对象的思想去设计我的业务实体，充分发挥面向对象思想的作用，不用关心这些设计是否能被持久化，显然NHibernate让我做到了这点，这是我在项目中选择使用ORM技术和NHibernate的最主要目的。
理由2：通过NHibernate和我们的合理设计，实现了对团队人员在开发的时候屏蔽掉数据库访问的技术细节，让我们更专注于业务和UI实现，在绝大多数情况下（复杂的报表查询和大批量操作依然可能需要存储过程实现）不必去关心SQL语句之类的，这对于一个绝大多数都是数据库操作的信息管理系统来说无疑具有很重要的意义。任何一个技术解决方案都不可能覆盖100%的需求，能用20%的精力，解决90%的问题就算是很成功了。
理由3：因为这个系统并不是只给一家医院使用，不同医院所使用的数据库产品是不一样的。从工程角度不能强制要求客户使用固定的数据库产品，NHibernate很大程度上屏蔽了不同数据库产品之间差异，使我不必对不同数据库产品分别写具体实现。
关于效率：“效率YY砖家”说：NHibernate效率低；“大型系统砖家”说：如果并发1W，NHibernate玩不转；弦哥说：
NHibernate这个技术本来长项就不在效率，而在以上3个理由（也许还有一些..），拿NHibernate和直接Ado.Net比效率就像拿c#和汇编比效率一样可笑。
Hibernate+Spring在J2EE里长期作为教科书式的解决方案，无论在国内还是国外都有非常多的大型系统成功案例，从这个意义来说也许Hibernate在效率上并非如此不堪，怎么到了.Net这边就成了效率低下的代名词，貌似说到Hibernate，各位砖家就以效率低一棒子打死，嗤之以鼻。
对于NHibernate的效率弦哥也整了些典型的场景和模拟数据用LoadRunner测了下，并非有各位砖家说的那么夸张，请问各位砖家测过没？
效率问题是一个复杂而综合的问题，如果忽略项目背景，实际业务需求，技术实现方式，以及多种软硬件因素的影响，片面的YY效率无疑是非常不严谨且非常可笑的。弦哥做所谓大并发，大数据量的电信，银行项目也有一些，对于这类项目上线运行的效率瓶颈几乎都在IO，往往都是通过Oracle优化专家和硬件方式解决。比如像上面那位“大型系统砖家”所说的1W并发的项目，同时并发1W是啥概念？没有用小机跑，整啥也白瞎，是吧....也不知道这位砖家见过小机没有....
为什么选择EXTJS
理由1：客户对UI交互要求非常高，又要求用B/S结构应用程序，Ext超强的UI组件交互能力正是我需要的
理由2：面向对象的Javacript编程，组件化编程，相比用以前的第三方服务器控件来说，可维护性，可读性和编码体验不知道要好多少...
理由3：由于客户对UI交互要求非常高，不用第三方UI组件是不可能的了，用第三方最大的风险是遇到Bug和自带功能不能满足的需求，ExtJs的开源和良好的面向对象能让我方便的重写源码实现任何我想要的功能。
理由4：我是内网系统，无需理会苛刻的网速问题
理由5：不可否认，在竞标或推销的时候美观的界面和交互对客户的好感度有相当大的影响。用EXT大多数情况下，我无需关系任何美工，Css，Html等烦人的细节
理由6：对于非常复杂的页面以及大表单页面，Ext在IE下确实有点延迟（这个效率问题的瓶颈是在客户端），所以我们在实施的时候都给客户用Google浏览器，涉及到医保的ActieX用除外（用google浏览器的IETab插件即可），Google浏览器下Ext的表现让人非常非常满意（V8引擎真强悍呀）...就算是很复杂的交互和大量组件存在于一个页，交互操作基本都是瞬时的
任何技术解决方案都不是银弹，ExtJs也不是UI解决方案的银弹，没有最好的技术，只有最适合你项目的技术，不知道各位“砖家”还有啥理由让我不用Ext....
为什么用依赖注入（具体用Unity实现）实现层间调用
因为医院信息系统业务比较复杂，虽然是产品化开发也做了很多参数配置，但在具体实施不同医院的时候，难免会涉及到修改代码。
在实施改代码的时候我希望做到两点：
一.在不改变原有产品发布代码版本的基础上去修改代码；
二.因为可能同时有几家医院用户，如果一家医院一套代码势必会增加公司的运营成本和管理难度。
所以我们在遇到需要修改代码的时候，新建一个文件（类）去继承产品发布版本代码的具体实现，并根据情况重写。这样我只需根据不同业务，不同医院修改配置文件即可
当然如果遇到因需求变化需要变更接口，那也没有办法了..不过因为HIS业务我们有10多年行业经验，所以在产品开发的时候对于业务都能考虑覆盖到。
当然需要说明的是在本项目中依赖注入并不只是应用在层间调用，依赖注入设计模式适用的业务场景我们都可以用它来实现解耦。
相比工厂模式，依赖注入容器有很多优点，如自动装配，实例对象的生命周期管理，可以传参数等。
为什么选择Asp.Net MVC+ExtJs
待续...
更多技术方案选择理由及思路待续...