.NET商业应用架构所要解决的若干问题（浅水滩）-CSDN博客

.NET商业应用架构所要解决的若干问题（

微软风风火火地发起了.NET革命，至今已经有4年的时间了，就从其本质的CLR和C#语法上来说，确实比J2EE要进步不少，连Martin Flower在举例说明OO方法时，都不自觉地使用C#来表达。然而若从商业应用的角度上来讲，微软却落后J2EE太多，这主要是从商业应用架构上来说。J2EE由于老主宗SUN公司相对弱势，导致不能很好地控制局面，因此J2EE阵营在发展初期经历了镇痛，但终于依靠开源来达到了空前的盛况，J2EE阵营注重标准、开放、良好架构的原则，并且现在也开始从微软最擅长的易用性向.NET发起攻击，J2EE对于.NET的优势恐怕要持续地保持下去了。反观.NET阵营，商业气息浓烈，由于微软的强势，导致任何的民间组织都倍受压力，微软的发展或者说插入点是从易用性出发，从一些hello world或者petstore的小项目来说，确实有不少优势，仿佛任何的项目都可以在弹指间完成，然后对于大项目事实上是这样的吗？微软的这些易用性通常靠鼠标点击来生成hard-code的代码，从重用性、维护、扩展角度上都要要付出巨大的代价。微软阵营习惯了去使用微软提供的API来完成项目，.NET阵营的特点是封闭、寡头执政、易用。从微软现在的情况看充其量只能在CLR和C#（JRE，和JAVA语法）或者说基础架构上对J2EE有较大优势，但是说到上层的OR-Mapping、表现层框架、AOP架构等，微软几乎无招架之力，而这些就是构建商业应用所最需要的架构，在很多.NET项目中很多的这些商业架构都是靠项目组自己来完成，其痛苦不堪而言。.NET和J2EE之争，仿佛就是6万人组成的严密组织纪律的高素质专业军团和几百万人组成的民间机构体制的竞争，是从“易用性->架构”和“架构->易用性”的2条路线方针的竞争，孰胜孰败，只有靠历史来评判了。

突然发现我扯远了，呵呵！也无所谓了，突来兴致多说点废话了，全当在.NET这个阵营里面生活太久的一些牢骚了。下面我言归正传，来谈谈.NET商业应用架构。首先，我想表达一下，为什么要有提出这个商业架构的问题，我想解决的是什么问题，总得来说商业架构所要解决的是：提高软件质量、加快开发效率、降低维护成本。下面就从商业应用的各个方面来说明：

l OR-MAPPING：我认为这是首要解决的问题，是整个商业应用中最需要提高的部分。有了OR-MAPPING，可以将以数据为中心的开发方式转移到以Model为中心的开发方式。不解决这个问题，永远也实现不了在《企业应用架构模式》一书中所说的三种基本模型种的最高层次Domain Model模式。不解决这个问题，3层企业应用中关键层次商业逻辑层的OO就不得执行。
问题：要求实现商业逻辑和持久化的解耦，项目要求可以跨数据库。
可能的解决方案：NHIBERNATE（现出于beta版本）、IBatis（1.0版本）

l 复杂查询：OR-Mapping不能解决复杂查询的问题，用NHIBERNATE中的HQL也不能很好解决这个问题（若查询牵扯到子对象，必须发送额外的查询语句，以及OR-Mapping中的entity不能完全容纳查询所需的字段）。
问题：各种商业所需的复杂查询实现需要动态构建很多查询语句，不能很好的统一，也不能很好的维护。
可能的解决方案：IBatis（1.0版本）

l 数据字典：或者说meta-data，即描述数据结构的结构
问题：很多商业项目要求可自定义字段，自定义报表，自定义查询列表等功能。另外，商业项目中很多查询条件、列表的代码过多重复。
可能的解决方案：暂无，不过可以参考MSCRM中的meta-DATA的实现。

l MVC：
问题：不用说了。
可能的解决方案：MAVERICK.NET、UIPB

l         事务：
问题：
    1、数据库的事务不能实现business transaction的功能，要实现required、nonsupported、supported、等形式的事务功能。
    2、开启事务、提交事务，回滚事务的代码过于重复，靠人为约束来实现难免会引入bug。
可能的解决方案：Enterprise Services （COM+）（但是将引入难以部署的问题）