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