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

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

时间: 2024-11-08 09:26:18

《企业应用架构模式》读后感的相关文章

大道至简第五章读后感

第五章 失败的过程也是过程 今天照样老师带领着我们阅读了大道至简第五章,阅读了<大道至简>的第五章,这章在前面的基础上又进了一步,有了技术和团队,加上有效的沟通,接下来就要接项目做工程. “虚有其表耳”,本章以<明皇实录>中的一句话来告诉我们一个深刻的道理:不要只求外表,只做形象工程,而是要透过表象,力求实质. 失败了不要紧,没有失败也就找不到自己的不足,也就不会发现自己的问题,更不用谈改进了.我们的前辈们就是在不断的失败中才总结出了“瀑布模型”“螺旋模型”等模型,方便了我们.但是

大道至简 第五章读后感

第五章 失败的过程也是过程 以得失而论,在瀑布模型与RUP模型之间,学习前者而不成,可思过程的本质:学习后者而不成,可得文字的架子. 如果懂得了所谓的模型原本都演化自那个简单的瀑布,那么文档是按XP写还是按RUP写,也就可以应时.应需,因地置宜,择善而从了. 越是简单的东西,往往越是接近于本质. 项目经理的工作,就是要去组织这个工程中的各个角色,使得分工明确,步调一致,共同地完成这个项目.四川有句地方话叫“做过场”,也有说成“走过场”的.“过场”是舞台术语,意思是角色从舞台一端出场,再走到另一端

大道至简 第五章 失败的过程也是过程 读后感

今天该写一写大道至简第五章读后感了. 首先是“做过程不是做工程”,过程是为了实现某种目的而经历的一些事情,过程有很多种,虽然经历了某种过程,但不一定能实现某种功能.做完过程的每一个阶段,并不等于做工程.做过程不是做工程的精义,也不是最终目的. 然后是“做过场”,做过场就好像是一种形式一样,做了没必要做的事情,就是浪费时间. 我们为什么做工程,不要忘了最终目的.目的,是实现客户的要求,工程只是一种实现的途径.最初做开发的前辈们,不用什么工程或者过程,也一样编出了程序,也一样解决了问题,也一样实现了

大道至简第七章读后感

大道至简第七章读后感——现实中的软件工程 “王不如远交而近攻,得寸,则王之寸:得尺,亦王之尺也.”——<战国策.秦策> 1:大公司手中的算盘 文中列举了IBM,Borland和Microsoft的一些体系,来说明大公司眼中的世界. 大公司们在标准.理论.语言上的争来夺去,未必全然出于“软件实现”的考虑.对统一理论.统一工具.统一过程的企图,其最终目的是在整个软件工程体系中的全面胜出.算 盘 上 的 绝 大 多 数 人 , 只 是 用 于 计 算 胜 负 的 一 枚 算子.所谓编程语言,只不过是

大道至简第五章阅读感想

第五章失败的过程也是过程 今天王建民老师依旧带领着我们阅读了大道至简第五章,第五章是失败的过程也是过程.通过前面的技术.团队和沟通,这章主要讲了关于做工程的问题. 文章开篇以一句<明皇实录>中的“虚有其表耳”来说明一个很重要的问题就是:不能只求外表,而是要透过表象,力求实质. 第五章的整体思想是让我们注重过程,因为有很多人从来不注重过程,只注重结果.然而过程对于一个编程人员也是非常重要,如果一个好的编程员从来不在乎程序的过程,只是关心最后程序是否能够实现,那么这个编程员一定不是一个好的编程员.

大道至简 第六章 读后感

说点什么呢,今天看了看大道至简第六章<从编程到工程>. 文章以<列子·说符>的“得其精而忘其粗,在其内而忘其外:见其所见,不见其所不见,视其所视,而遗其所不视.”为题记.第一节讲了“语言只是工具”,作者讲述了他曾经对一些编程语言的看法.他曾经也热衷于讨论语言的优劣,但是他现在不这样了,他已经不再专注于语言, 正如他在第一章中写到的一样:成天讨论这门语言好,或者那门语言坏的人,甚至是可悲的.确实,程序的好坏不在于语言,在于算法. 第二节又写了“程序”,程序=算法+结构,编程的精义于此

《大道至简》第一章读后感

经常听见有人抱怨编程太难,说自己不是学软件的料,那么他们真该好好看看<大道至简>这本书,相信他们看完这本书后会有很大收获. <大道至简>第一章引用了一个很简单的故事“愚公移山”,用这个故事很好的概述了我们在完成一个项目时所要进行的步骤.听上去“愚公移山”和编程简直是风马牛不相及,但是看过作者的叙述又有原来如此的感觉.其实编程并没有什么难懂的,就和我们日常生活一样,发现问题,分析问题,提出解决问题的方案,实施,和后续的验收.例如某天我们突然发现家里放不出水了,这就是发现问题,我们会观

大道至简第三章读后感

---恢复内容开始--- 大道至简第三章的是团队的问题.我们知道,随着人们生活水平的不断提高,用户对计算机软件的功能要求也日趋上升.这样一来,计算机软件就变得越来越复杂,规模变得越来越庞大,源代码的量也越来越多.在这种市场需求和自身发展的共同要求之下,一个团结而高效的开发团队的作用就不言而喻了.那么如何打造一支强有力.听指挥.能干活的开发团队呢?这一章作者就这个问题和我们展开了讨论. 作者着重的强调了项目经理在开发团队中的作用.首先声明一点,这并不是说团队的开发人员不重要,作者从始至终都认为编程

一切都是为了实现-大道至简第六章读后感

大道至简第六章的内容比较多,也比较深.或者说这一章作者是从一个更高的层次.更开阔的视野.更独特的角度来解读软件工程这四个字的具体含义的. 作者的这些肺腑之言都是作者在软件行业工作了多年之后总结出来的.开发技术对一个软件产品质量的好坏和最终的成功的影响并虽然不能说是一点也没有,但也不是很大.真正起到决定性因素的不是那些技术细节,而是一个高度过程化.通晓方法论.拥有大量工具的开发团队或者是开发公司.在这个团队里面,无论是对项目经理还是开发经理甚至是一个普通的开发人员的要求都是很高的.团队内的每个人必

《大道至简》第一章读后感和伪代码

阅读了<大道至简>第一章,感到作者对编程的精义分析非常具体形象,引用<愚公移山>的故事,说明了编程的本质.又将他们扮演的管理者,技术人员,程序分析师众多形象展现出来.又在困惑人们的"我能不能学会编程"这一问题做出回答,作者列举生活实例,给出了肯定的答案,将很多抽象的东西,简单化,通过最常见的生活中的实例介绍"大道". import java.大道至简.*; public class.yishan.*; { public static void