前端重点工程师企业级系统架构的理解Word文件下载.docx
- 文档编号:22288755
- 上传时间:2023-02-03
- 格式:DOCX
- 页数:12
- 大小:258.29KB
前端重点工程师企业级系统架构的理解Word文件下载.docx
《前端重点工程师企业级系统架构的理解Word文件下载.docx》由会员分享,可在线阅读,更多相关《前端重点工程师企业级系统架构的理解Word文件下载.docx(12页珍藏版)》请在冰豆网上搜索。
AD:
这个是最基本三层架构模式。
体现层充当系统界面呈现以及UI逻辑角色,也就是说,UI(顾客界面)属于体现层;
举一种对于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(PreentationModel),它可以说是MVP变体,在PM中,视图不定义接口,这里模型只是表达视图状态类,视图中元素被直接绑定到模型属性上。
例如在WPF中,WPF就先天具备数据双向绑定机制以及事件告知属性机制。
因此它特别合用于WPF,Sliverlight等等。
在开始业务层之前,不得不说一种前提,在一种小型项目中,直接让体现层调用业务层,足以解决所有问题。
但是,当项目大到使用各种体现形式,如使用了各种UI技术,ASP.NET,WPF,移动设备等等,就要考虑在你体现层和业务层之间增长一种层,以至于让体现层和业务层解耦,由于业务层作为一种业务中间件平台,最佳不要暴露于体现层中,这个层就是传说中服务层。
架构图又演化为:
服务层事实上并不执行任何详细工作,其功能在于组织各个业务对象,服务层将业务层所有细节对体现层都隐藏起来,服务器将组织业务逻辑层中组件,并且通过数据迁移对象(DTO)与体现层交互,因而就产生一种DTO模型。
为了实现服务可重用性,需要使用服务接口,体现层通过规定接口访问功能。
服务实现继承服务接口,而服务实现专注于业务层调用。
对于服务层,惯用办法涉及Web服务、.NETRemoting、Rest以及WCF技术。
本人比较建议使用WCF作为服务,由于可以以便地通过配备达到远程调用服务目。
服务层消除了两个体现层和业务层之间耦合,服务层可以实现一种远程接口,达到多UI技术甚至多平台上通信。
固然增长服务层也有缺陷,如果使用WCF服务,会增长系统调用开销,进而影响性能。
业务层中包括系统所需要业务过程上实现,并与下层数据访问层交互。
咱们普通也叫做业务层叫做业务逻辑层,但我以为业务逻辑层是属于业务层一方面,业务逻辑更专注于业务上逻辑算法实现。
由于业务层还可以涉及其她方面。
业务层必要涉及对业务实体尽心建模对象模型,表达了客户所有方略和需求业务规则,因而就产生了领域模型。
(PS:
如果这里你不使用领域模型,那么需要采用业务规则层进行业务功能上业务规则验证和控制)
领域模型涉及对实体属性定义,办法定义以及实体与实体之间关系。
从这个角度上看,UML建模至关重要,通过对UML动态图和静态图描述,可以映射到领域模型中。
从服务层刚才讲到了DTO模型,这里需要一种机制将DTO转化为领域模型,因此产生了DTO映射层(DTOMapper)。
此外业务层还涉及核心中间件技术,涉及第三方组件,以及工作流引擎等等。
业务层需要考虑到某些与数据访问层交互设计模式,模式中涉及事物脚本模式、表模块模式、活动记录模式、领域模型模式。
事物脚本模式是通过办法来执行业务流程,它是一种过程式模型,事物脚本每个办法均有一种特定事物脚本,它侧重于业务上一系列流程上顺序操作,它实现起来很简朴,但是它有个致命缺陷就是它会导致诸多重复代码。
表模块模式比起事物脚本模式,具备一定构造,它思想也很简朴,每个数据表都定义一种业务组件(实体类,实体操作类),在.NET中更多使用DataSet作为表模型数据交互。
但是它也有一种缺陷就是它是从数据库驱动它不适合于大量数据表以及数据表之间复杂关系。
活动记录模式中对象中,可以包括数据和办法。
它接近于数据表构造,它对象中执行办法中可以包括CRUD操作,验证算法,以及其她计算功能。
普通来说,领域模型不是太复杂,活动记录模式是个好选取。
固然她也存在问题,同样地,它对于复杂业务上,维护成本也很高,并且如果需求变更导致数据库修改,就需要调节记录对象模型中有关代码。
典型应用:
LINQ-TO-SQL以及CastleActiveRecord。
领域模型模式是从领域驱动设计中衍生来,它是以业务为核心设计模式。
它对于复杂业务逻辑,相称合用。
前三种方式使用是以数据驱动方式,数据驱动方式特点简朴,但是当系统到了一定规模后,就会到难以维护限度。
数据访问层目很明确,重要作为提供数据持久化功能,涉及数据读取和写入,此外还必要涉及事务解决,并发控制等等。
操作数据库办法可以有两种方式,ORM方式,ADO.NET方式。
ORM可以采用某些第三方ORM框架来实现,ADO.NET采用ASP.NET自带数据库操作来实现。
不同数据库具备不同持久化实现,因而这里添加一种存储仓库接口层,来适应不同数据库实现,这里你可以使用IOC依赖注入方式进行数据库选型,可以运用Unity、Spring.NET、CastleIOC容器等等。
最后各个层中都可以依赖于公共基本设施层。
公共基本设施层可以涉及Common通用模块,Logging日记模块,Exception异常模块,Configuration配备模块,DI依赖注入模块,单元测试模块以及第三方组件(例如NHibernate、Sprint.NET、Castle、Quartz筹划任务等等)
最后图:
总结:
项目类型、项目规模以及业务上需求,都影响着系统架构设计,系统架构并不是一层不变,没有最佳架构,只有更好架构,并且从项目中多思考系统扩展性。
文中对于架构分析,只是从普通角度上去考虑,在项目中,您还需要依照实际状况去做调节。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 前端 重点 工程师 企业级 系统 架构 理解
![提示](https://static.bdocx.com/images/bang_tan.gif)