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

摘自：http://ron.javaeye.com/blog/132072

.NET商业应用架构。首先，我想表达一下，为什么要有提出这个商业架构的问题，我想解决的是什么问题，总得来说商业架构所要解决的是：提高软件质量、加快开发效率、降低维护成本。下面就从商业应用的各个方面来说明：

1. OR-MAPPING：我认为这是首要解决的问题，是整个商业应用中最需要提高的部分。有了OR-MAPPING，可以将以数据为中心的开发方式转移到以Model为中心的开发方式。不解决这个问题，永远也实现不了在《企业应用架构模式》一书中所说的三种基本模型种的最高层次Domain Model模式。不解决这个问题，3层企业应用中关键层次商业逻辑层的OO就不得执行。
   问题：要求实现商业逻辑和持久化的解耦，项目要求可以跨数据库。
   可能的解决方案：NHIBERNATE（现出于beta版本）、IBatis（1.0版本）
2. 复杂查询：OR-Mapping不能解决复杂查询的问题，用NHIBERNATE中的HQL也不能很好解决这个问题（若查询牵扯到子对象，必须发送额外的查询语句，以及OR-Mapping中的entity不能完全容纳查询所需的字段）。
   问题：各种商业所需的复杂查询实现需要动态构建很多查询语句，不能很好的统一，也不能很好的维护。
   可能的解决方案：IBatis（1.0版本）
3. 数据字典：或者说meta-data，即描述数据结构的结构
   问题：很多商业项目要求可自定义字段，自定义报表，自定义查询列表等功能。另外，商业项目中很多查询条件、列表的代码过多重复。
   可能的解决方案：暂无，不过可以参考MSCRM中的meta-DATA的实现。
4. MVC：
   问题：不用说了。
   可能的解决方案：MAVERICK.NET、UIPB
5. 事务：
   问题：
       1、数据库的事务不能实现business transaction的功能，要实现required、nonsupported、supported、等形式的事务功能。
       2、开启事务、提交事务，回滚事务的代码过于重复，靠人为约束来实现难免会引入bug。
   可能的解决方案：Enterprise Services  （COM+）（但是将引入难以部署的问题）
6. 统一页面中的数据验证、读取、和加载
   问题：很多页面的数据验证、读取、加载都类似，但重复地写过于繁琐。要求如日期、金额等格式在整个项目中统一，开发人员在每个页面中做同样的繁琐操作不利用维护。
   可能的解决方案：无
7. 日志：
   问题：在每个商业应用中，都要写很多类似的日志代码，过于繁琐。
   可能的解决方案：Spring.NET、Aspect#、EDRA
8. 权限验证：
   问题：在每个商业应用中，都要写很多类似的权限验证代码，过于繁琐。
   可能的解决方案：Spring.NET、Aspect#、EDRA
9. 解决并发冲突：
   问题：在WEB开发中的并发问题尤其严重，每个页面都可能并多个用户同时打开，架构要处理这种并发问题。
   可能的解决方案：《企业应用架构模式》中的第6章描述。