.NET的WEB商业应用架构所要解决的若干问题(原创)
微软风风火火地发起了.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商业应用架构。首先,我想表达一下,为什么要有提出这个商业架构的问题,我想解决的是什么问题,总得来说商业架构所要解决的是:提高软件质量、加快开发效率、降低维护成本。下面就从商业应用的各个方面来说明:
- 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章描述。
分享到:
相关推荐
C# .net 通用开发架构
走过Asp.net学习入门阶段后,真正开始着手开发一个Web项目时,才发现错综复杂的数据与关联根本就不是SqlDataSource和AccessDataSource数据源控件能简单解决的,而恰恰是被忽视了的一个ObjectDataSource数据源控件才...
适读人群 :适合软件架构师和想成为软件架构师的人阅读 ... 本书着重介绍软件架构相关的内容,非常适合软件架构师和想成为软件架构师的人阅读,而且首席开发者和各种.NET应用程序的开发者也能从本书获益。
《.Net微服务:容器化.Net应用架构指南.pdf》是.Net平台上一本非常不错的,关于微服务架构的书籍,值得大家学习。
本书主要讲.NET企业架构设计, 如分层架构、领域架构、领域驱动、领域模型、CQRS、领域事件、事件溯源、基础设施等,非常实用。
全书共分9章,主要讲解ASP.NET基础、Web窗体技术与用户界面设计、数据访问层与业务逻辑层实现技术、数据控件与视图层实现技术、应用其他常用技术完善系统、ASP.NET MVC框架、持久化技术NHibernate、集成框架Spring...
Microsoft.NET企业级应用架构设计 第二版 扫描版的
Microsoft+.NET企业级应用架构设计 一本好书,无需多言
适用于依照分层结构设计的交易式或 OLTP 应用程序,而且利用下列技术,可以将这些应用程序分散于许多实体层中:ASP.NET、Web 服务、企业服务 (COM+)、远程处理、ADO.NET 和 SQL Server。本手册中所提到的某些设计...
简单的.NET下的CS架构系统,安全,放心,非常的实用!!!!!!!!!!!!!!!!!!!!!!!!!
.net架构图,可以清晰的了解微软.net架构是怎么样的
Microsoft .NET企业级应用架构设计
.NET应用程序架构设计 原则 模式与实践 +源码,第一部分为书籍,后续的压缩包为源代码文件,上传以供各位同仁一起参考学习!
基于c#的asp.net三层架构的博客系统,包括dal、bll、model、ui界面的设计
该文档从单层架构、双层架构再到三层架构,以一个留言板实例来讲述,通俗易懂。
简单的asp.net三层架构学习代码,对初学者挺有用的
ASP.NET三层架构网站源代码ASP.NET三层架构网站源代码ASP.NET三层架构网站源代码ASP.NET三层架构网站源代码ASP.NET三层架构网站源代码
asp.net三层架构解决方案实例,对初学者有一定的参考作用。
使用一个简单的留言板实例讲解.NET三层架构开发。包括BLL/DAL/UI层具体代码,内含数据库(VS2010+SQL2000)
.NET 微服务 容器化.NET应用架构指南中文版本,英语可以的,建议阅读英文文档