码迷,mamicode.com
首页 > 其他好文 > 详细

《企业应用架构模式》读后感

时间:2019-07-04 00:14:50      阅读:103      评论:0      收藏:0      [点我收藏+]

标签:占位符   解决   独立   代码   具体类   出现   三种模式   执行时间   命令   

1.企业应用架构模式

  • 架构

    • 架构的定义:最高层次的系统分解、系统中不容易改变的部分。

    • 架构中最有价值的部分是:分层设计。

  • 企业应用的特点

    • 一般都涉及持久化数据

    • 一般都涉及大量数据

    • 一般还涉及很多人同时访问系统

    • 还涉及大量操作数据的用户界面屏幕

    • 通常还与企业周围的其他企业应用集成

    • 还存在数据的概念不一致性

    • 复杂的业务”无逻辑“

    • 系统庞大,须具有”分而治之“的思想

  • 企业应用的种类(抽象、提炼)

    • 处理大量数据的系统

    • 用户界面高要求的系统

    • 数据管理系统

  • 关于性能的考虑

    • 响应时间

    • 响应性:进度条

    • 等待时间

    • 吞吐率

    • 负载

    • 效率

    • 可伸缩性

  • 模式

    • 模式最主要的是”意图“和”概要”

    • 所有的模式都是行为方式的抽象概念,都是不完备的,需要不断学习完善。

 

2.分层

  • 专业的人做专业的事情

  • 分层的好处

    • 可以将某一层当初一个有机整体来理解

    • 可以替换某层的内部实现,只要提供的服务相同即可

    • 可以降低耦合性,把各个层次的依赖性减到最低

    • 分层有利于标准化工作

  • 企业应用层次的演化

    • 三个基本层次:表现层、领域层、数据源层

 

3.组织业务逻辑

  • 业务逻辑的模式

    • 三种模式:事务脚本、业务模型、表模块。

    • 事务脚本:一个过程控制一个动作的逻辑。

    • 业务模型:每个对象都承担一部分相关的逻辑 。

    • 表模块:以表为单位设计的模式。

  • 将处理业务逻辑分为业务层、服务层

    • 服务层:放置事务控制和安全校验,提供一个易于使用的API。

 

4.映射到关系数据库

  • 架构模式

    • 主要时解决驱动领域逻辑访问数据库的方式

    • 把领域模型和数据库完全独立,让间接层完成领域对象和数据库表之间的映射

  • 行为问题

    • 行为时从数据库读取数据以及修改数据的动作

    • 需要保证数据的一致性

    • 延迟加载也是必要的思想,延迟加载主要是拥有一个对象引用的占位符

  • 读取数据

    • 读取数据的方法可以看作一个查找器

    • 读取数据关键的问题是性能问题

    • 读取数据的准则是尽量进行批量操作,避免重复查询相同的表

  • 结构映射模式

    • 关系的映射:对象和键的映射

    • 依赖映射可以简化映射关系

  • 继承

    • 单表继承:所有类建立一个表

    • 具体表继承:每个具体类建立一个表

    • 类表继承:一个层次的每个类建立一个表

  • 建立映射

    • 两步映射:先把内存方案转换为逻辑数据存储方案,然后从逻辑数据存储到物理数据存储

  • 使用元数据

    • 元数据映射:数据库中的列映射到对象的域。

  • 数据库链接

    • 数据库链接建立开销很大,因此需要建立一个连接池

    • 一个事务必须保证每个命令都是同一个链接发出

    • 链接使用完后需要关闭,一般是用垃圾回收机制关闭链接

    • 避免使用select* ,使用预编译机制避免sql注入。

 

5.Web表现层

  • web服务器应用程序

    • 使用脚本:接受HTTP请求数据,通过写出stream形式输出这个字符串

    • 服务器页面:程序和返回的文本页组合在一起

    • 把非表现层逻辑剥离出来

  • 视图模式

    • 转换视图、模板视图和两步视图

    • 转换视图:程序的一种转换风格

    • 模板视图:网页结构中编写表现层,页面中嵌入标签。不过这样会导致代码混乱难以维护。

    • 两步视图:可以理解为前后端分离,两者独立业务逻辑更清晰,但是在性能方面有一定的损耗。

  • 输入控制器模式

    • 一个页面准备一个控制器

    • 控制器分离出单独的对象,一个动作对应一个页面。

 

6.并发

  • 并发问题

    • 开发者能简单的避开并发问题是因为有了事务管理程序。

    • 离线并发:多数据库事务中数据操作的并发控制。

    • 更新丢失:A先更新数据1,然后B更新数据1,而B在A之前更新完数据。那么会导致B更新的数据就会丢失,因为B在A开始之后开始,却在A结束之前结束,导致A没有读到B的更新。

    • 不一致读:A读数据过程中,B修改了数据,导致A读取的不是最新的数据。

  • 执行语境

    • 请求:应对软件工作的外部环境发出的单个调用。

    • 会话:客户端和服务端长时间的交互

    • 事务:多个请求看作是单个请求

  • 隔离与不变性

    • 对数据加锁

    • 识别不变的数据

  • 乐观并发控制和悲观并发控制

    • 乐观锁:冲突检测,适用场景是冲突少且冲突结果不严重。

    • 悲观锁:冲突避免,减少并发程度,但是会产生大量阻塞影响性能。

  • 避免不一致读

    • 悲观锁策略是读数据加一个读锁(共享锁),写数据加一个写锁(排他锁)。

    • 乐观锁策略是将冲突检测建立在数据的某种版本标记上。

  • 死锁

    • 悲观锁技术有一个特别的问题就是死锁。

    • 死锁:A对数据1加了锁,B对数据2加了锁,如果后面A要用到数据2,B要用到数据1。因为B对数据2加了锁,A就会等待B执行完,而B获取数据1也需要等待A执行完。这样A和B之间就出现了死锁。

    • 处理死锁的一个方法是超时控制和检测机制。

    • 尽量避免死锁才是最有效的解决方案:一开始获取所有锁,或者按照相同的顺序获取锁。

  • 事务

    • ACID:原子性、一致性、隔离性、持久性。

    • 长事务:跨越多个请求的事务称做长事务。

    • 延迟事务:尽可能晚的打开事务,可以减少事务执行时间,但是可能会导致不一致读。

    • 锁升级:如果一个事务锁住了多行数据,数据库无法处理那么多锁,就会升级为表锁。

    • 减少事务隔离:可串行化的、可重复读、读已提交、读未提交。

      • 可串行化:完全隔离,所有事务时串行化执行的。

      • 可重复读:允许幻读,幻读就是A向一个集合中加入一批元素,而B只读到其中一部分数据。通常是插入数据引起的。

      • 读已提交:重新读取已经提交的数据

      • 读未提交:允许脏读,读取没有提交的数据,而这些数据又被回滚了,这种情况称之为脏读。

    • 业务事务和系统事务

      • 系统事务:通常说的数据库事务

      • 业务事务:是一组业务操作,业务也期望它有ACID的属性,解决这一问题的方案是离线并发。

      • 离线并发:把业务事务分成一系列的短事务。

      • 业务事务最大的问题是隔离性。

  • 离线并发控制的模式

    • 处理离线并发问题的首选是乐观离线锁。因为它易于实现,提供最好的灵活性。

  • 应用服务器并发

 

《企业应用架构模式》读后感

标签:占位符   解决   独立   代码   具体类   出现   三种模式   执行时间   命令   

原文地址:https://www.cnblogs.com/wuchangliang/p/11129775.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!