谈谈对于企业级系统架构的理解(转)

原文地址:http://www.cnblogs.com/liping13599168/archive/2011/05/11/2043127.html

在我们刚开始学习架构的时候,首先会想到分层的概念,分层架构比较经典的是三层架构,那么,什么是三层架构呢?它包括表现层,业务层,数据访问层;而对于一个新手来说,从抽象意义上的三层架构,逻辑上就划分为三个层。

这个是最基本的三层架构模式。

表现层充当系统的界面呈现以及UI逻辑的角色,也就是说,UI(用户界面)属于表现层;

举一个对于asp.net WebForm来说,人们喜欢把对于UI的控制逻辑(服务器控件的读取、设置、事件等等)写在页面的后置隐藏代码中,并且依赖业务逻辑层。当然,服务器控件支持数据绑定的功能,可以通过数据源进行绑定控件。这样就可以节省在后置隐藏中的代码。

因此,我们就可以把表现层分为UI用户界面以及UI逻辑:

UI用户界面的职责只是作为数据输入和输出后的展示工作。

UI逻辑的职责是负责业务逻辑层以及UI用户界面之间的数据交互,并且尽可能地让UI逻辑不依赖于UI技术

其中UI用户界面的实现方式有很多,包括ASP.NET,WinForm,WPF,Silverlight,移动Web,智能设备等等。

将表现层中UI页面和UI逻辑分离的策略中,当前使用最多的两种模式是MVC模式和MVP模式。

MVC模式,即模型-视图-控制器模式,通过视图触发并执行某个操作,调用控制器,通过控制器去操作业务层,最终返回模型,在视图中进行展示。这里的模型可以是一个领域模型(DM),也可以是一个数据迁移对象(DTO)。

MVP模式,即模型-视图-展示器模式,和MVC模式有点像,不同的是MVP中视图和模型是被完全分离出来的,视图中定义一个接口,而展示器通过调用该接口的方法以控制视图。因此,视图和模型是松散的,展示器也充当了一个控制器的角色,同时它也不依赖于UI技术。

另外再介绍一种模式PM(Preentation Model),它可以说是MVP的变体,在PM中,视图不定义接口,这里的模型只是表示视图状态的类,视图中的元素被直接绑定到模型属性上。例如在WPF中,WPF就先天的具有数据双向绑定机制以及事件通知属性机制。

所以它特别适用于WPF,Sliverlight等等。

在开始业务层之前,不得不说一个前提,在一个小型项目中,直接让表现层调用业务层,足以解决所有问题。但是,当项目大到使用多种表现形式,如使用了各种UI技术,ASP.NET,WPF,移动设备等等,就要考虑在你的表现层和业务层之间增加一个层,以至于让表现层和业务层解耦,因为业务层作为一个业务中间件的平台,最好不要暴露于表现层中,这个层就是传说中的服务层。架构图又演化为:

服务层实际上并不执行任何具体的工作,其功能在于组织各个业务对象,服务层将业务层所有的细节对表现层都隐藏起来,服务器将组织业务逻辑层中的组件,并且通过数据迁移对象(DTO)与表现层交互,因此就产生一个DTO模型。

为了实现服务的可重用性,需要使用服务接口,表现层通过规定的接口访问功能。服务的实现继承服务接口,而服务的实现专注于业务层的调用

对于服务层,常用的方法包括Web服务、.NET Remoting、Rest以及WCF技术。

本人比较建议使用WCF作为服务,因为可以方便地通过配置达到远程调用服务的目的。

服务层消除了两个表现层和业务层之间的耦合,服务层可以实现一个远程接口,达到多UI技术甚至多平台上的通信。

当然增加服务层也有缺点,假如使用WCF服务,会增加系统的调用开销,进而影响性能。

业务层中包含系统所需要业务过程上的实现,并与下层的数据访问层交互。

我们通常也叫做业务层叫做业务逻辑层,但我认为业务逻辑层是属于业务层的一方面,业务逻辑更专注于业务上逻辑算法的实现。因为业务层还可以包括其他的方面。

业务层必须包括对业务实体尽心建模的对象模型,表达了客户的所有策略和需求的业务规则,因此就产生了领域模型

(PS:如果这里你不使用领域模型,那么需要采用业务规则层进行业务功能上的业务规则的验证和控制)

领域模型包括对实体的属性定义,方法定义以及实体与实体之间的关系。从这个角度上看,UML建模至关重要,通过对UML动态图和静态图的描述,可以映射到领域模型中。

从服务层刚才讲到了DTO模型,这里需要一个机制将DTO转化为领域模型,所以产生了DTO映射层(DTOMapper)。

另外业务层还包括核心中间件技术,包括第三方组件,以及工作流引擎等等。

业务层需要考虑到一些与数据访问层交互的设计模式,模式中包括事物脚本模式、表模块模式、活动记录模式、领域模型模式。

事物脚本模式是通过方法来执行业务流程,它是一个过程式模型,事物脚本的每个方法都有一个特定的事物脚本,它侧重于业务上一系列流程上的顺序操作,它实现起来很简单,但是它有个致命的缺点就是它会造成很多重复的代码。

表模块模式比起事物脚本模式,具有一定的结构,它的思想也很简单,每个数据表都定义一个业务组件(实体类,实体操作类),在.NET中更多的使用DataSet作为表模型的数据交互。但是它也有一个缺点就是它是从数据库驱动它不适合于大量的数据表以及数据表之间的复杂关系。

活动记录模式中的对象中,可以包含数据和方法。它接近于数据表的结构,它的对象中执行方法中可以包含CRUD操作,验证算法,以及其他的计算功能。一般来说,领域模型不是太复杂,活动记录模式是个好选择。当然他也存在问题,同样地,它对于复杂的业务上,维护的成本也很高,并且如果需求变更导致数据库修改,就需要调整记录对象模型中的相关代码。

经典应用:LINQ-TO-SQL以及Castle ActiveRecord。

领域模型模式是从领域驱动设计中衍生来的,它是以业务为核心的设计模式。它对于复杂的业务逻辑,相当适用。前三种方式使用的是以数据驱动方式,数据驱动方式特点简单,但是当系统到了一定的规模后,就会到难以维护的程度。

数据访问层的目的很明确,主要作为提供数据持久化的功能,包括数据的读取和写入,另外还必须包括事务处理,并发控制等等。

操作数据库的方法可以有两种方式,ORM方式,ADO.NET方式。

ORM可以采用一些第三方的ORM框架来实现,ADO.NET采用ASP.NET自带的数据库操作来实现。

不同的数据库具有不同的持久化实现,因此这里添加一个存储仓库接口层,来适应不同的数据库实现,这里你可以使用IOC依赖注入方式进行数据库选型,可以利用Unity、Spring.NET、Castle的IOC容器等等。

最后各个层中都可以依赖于公共基础设施层

公共基础设施层可以包括Common通用模块,Logging日志模块,Exception异常模块,Configuration配置模块,DI依赖注入模块,单元测试模块以及第三方组件(例如NHibernate、Sprint.NET、Castle、Quartz计划任务等等)

最终图:

总结:项目类型、项目规模以及业务上的需求,都影响着系统架构的设计,系统架构并不是一层不变的,没有最好的架构,只有更好的架构,并且从项目中多思考系统的扩展性。文中对于架构的分析,只是从通常的角度上去考虑,在项目中,您还需要根据实际情况去做调整。

谢谢大家阅读!

时间: 2024-10-25 13:43:14

谈谈对于企业级系统架构的理解(转)的相关文章

谈谈对于企业级系统架构的理解

在我们刚开始学习架构的时候,首先会想到分层的概念,分层架构比较经典的是三层架构,那么,什么是三层架构呢?它包括表现层,业务层,数据访问层:而对于一个新手来说,从抽象意义上的三层架构,逻辑上就划分为三个层. 这个是最基本的三层架构模式. 表现层充当系统的界面呈现以及UI逻辑的角色,也就是说,UI(用户界面)属于表现层: 举一个对于asp.net WebForm来说,人们喜欢把对于UI的控制逻辑(服务器控件的读取.设置.事件等等)写在页面的后置隐藏代码中,并且依赖业务逻辑层.当然,服务器控件支持数据

系统架构的理解

谈对于企业级系统架构的理解 在我们刚开始学习架构的时候,首先会想到分层的概念,分层架构比较经典的是三层架构,那么,什么是三层架构呢?它包括表现层,业务层,数据访问层:而对于一个新手来说,从抽象意义上的三层架构,逻辑上就划分为三个层. 这个是最基本的三层架构模式. 表现层充当系统的界面呈现以及UI逻辑的角色,也就是说,UI(用户界面)属于表现层: 举一个对于asp.net WebForm来说,人们喜欢把对于UI的控制逻辑(服务器控件的读取.设置.事件等等)写在页面的后置隐藏代码中,并且依赖业务逻辑

企业级系统架构设计技术与互联网应用技术结合主题一 大规模并发性能问题探讨

何谓大规模并发,不同层面有不同的理解 企业应用(Intranet):千级强并发,万级弱并发(在线用户),十万级用户 大型企业ERP.供应链,大型企业HR.办公OA 互联网应用(Internet):百万级强并发,千万级弱并发(在线用户),亿级用户/ 门户网站(新浪.腾讯) 平台级电子商务(阿里巴巴.淘宝网.拍拍网) 搜索引擎(百度) 电子商务企业应用(Intranet + Internet):十万级强并发,百万级弱并发(在线用户),千万级用户 B2C电子商务(京东.凡客.一号店) 垂直型电子商务(

对软件设计和系统架构的理解

最先接触系统架构的时候,是在学软件工程这门课的时候.当时觉得系统架构很遥远.之后的一段时间里,先后参与和发起了不少的课题设计项目. 从开始写starwar的时候,一个java applet 程序,照着别人敲出来,很疑惑哪些类和方法是怎么调用的.唯一的收获是,知道了可以将很多功能分成不同的函数.很多功能包装成类. 在代码很多的时候便于管理和编写. 之后的图书管理系统和在线考试系统.一个是 <.net>的课题设计,一个是 <数据库理论>的 课题设计.都是用php语言写的代码.图书管理系

谈谈运行稳定性好效率高的千万级大型网站系统架构性分析

千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题. 数据库海量数据处理:负载量不大的情况下select.delete和update是响应很迅速的,最多加几个索引就可以搞定,但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题.另外在高UPDATE的情况下,更新一个聚焦索引的时间基本上是不可忍受的.索引和更新是一对天生的冤家. 高并发死锁:平时我们感觉不到,但数据库死锁在高并发的

深入理解Android(1)__系统架构

最近一直在为Android的系统级开发发愁,很多东西云里雾里,还是觉得是基础知识不够扎实的缘故,所以,思考再三,还是决定认真研读一下<深入理解Android卷I.II>,最近深入手了一本<深入理解Android卷III>,希望能够在研读的过程中,将心得笔记写下,与Android爱好者一起学习,共同进步. 下面我们就进入正题吧. ------------------------------------------------------------------------------

深入理解Tomcat系列之一:系统架构

前言 Tomcat是Apache基金组织下的开源项目,性质是一个Web服务器.下面这种情况很普遍:在eclipse床架一个web项目并部署到Tomcat中,启动tomcat,在浏览器中输入一个类似http://localhost:8080/webproject/anyname.jsp的url,然后就可以看到我们写好的jsp页面的内容了.一切都是那么自然和顺理成章,然而这一切都是源于tomcat带给我们的,那么在tomcat背后,这一切又是怎么样发生的呢?带着对tomcat工作原理的好奇心,我决定

[转载]企业级应用架构(NHibernater+Spring.Net+MVC3)

本人已经从事公司两套这类架构系统的开发工作啦!对于这套架构,我惊叹不已!BPS和CMS系统都是采用这套架构.但本人也同时渐渐发现了这套架构有诸多 不足之处,于是本人利用闲暇时光进一步改进了这套架构.新架构是基于“领域模型”的企业级应用架构模式,使用了 NHibernater+Spring.Net+MVC3的框架技术搭建.即便的是1.0版本,我也惊叹其几乎趋于完美了!这套架构是马丁.福勒关于“企 业级应用架构模式”理论的.Net实践. 架构基于三层模型,使用了接口技术.工厂模式.MVC模式.适配器

SOA系统架构

一.SOA原理与应用 1.SOA原理 SOA(Service-oriented architecture,面向服务架构). SOA的价值在于跨越了不同应用系统.不同技术的整合,这种整合改变现有的商业模型. SOA是在计算环境下设计.开发.应用.管理分散的逻辑(服务)单元的一种规范.这个定义决定了SOA的广泛性.SOA要求开发者从服务集成的角度来设计应用软件,即使这么做的利益不会马上显现.SOA要求开发者超越应用软件来思考,并考虑复用现有的服务,或者检查如何让服务被重复利用.SOA鼓励使用可替代的