读书笔记: 企业应用架构模式

https://book.douban.com/people/fleure/annotation/4826290/

远程外观(Remote Facade)

<原文开始>我更倾向于粗粒度的结构和较少的远程外观。</原文结束> <原文开始>对于远程外观而言，最大的错误之一就是把领域逻辑放在其中。我再三强调：“远程外观没有领域逻辑。”任何外观都应该是一层薄薄的皮肤并且只负责很小一部分责任。</原文结束> ## 离线乐观锁 <原文开始>应该在任何系统的业务事务冲突中优先考虑（乐观锁）。悲观锁可以作为乐观锁的补充，因此不要考虑何时使用乐观锁，而应该考虑什么情况下光有乐观锁还不够。</原文结束> ## 数据传输对象(Data Transfer Object) <原文开始>很多方面，数据传输对象都是我们被告知永远不要写的对象之一。它经常只不过是一堆字段及它们的 getter 和 setter 方法。这种对象的价值在于允许你在一次调用中传输几部分的信息，这是分布式系统的本质。</原文结束> Form Object 也可以算是一种 DTO 吧。 <原文开始>数据传输对象的常见格式是记录集。... 记录集就是一个为 SQL 数据库服务的数据传输对象。</原文结束> <原文开始>序列化的一个重要用因素是连接双方的数据传输对象的同步。从理论上说，无论何时服务器改变了数据传输对象的定义，客户也都应该可以同时更新它的数据。</原文结束> 数据传输对象会承担序列化/反序列化的职责。 thrift 那类远程调用工具做的事情，也正是数据传输对象了。 ## 远程外观 (Remote Facade) <原文开始>任何对象可能作为远程对象使用时，经常需要一个粗粒度的接口来减少完成某些任务所需要的调用次数。这不仅会影响你的方法调用，同样还会影响你的对象。现在，一个调用中就会包括访问和更改订单及订单的功能，而不会像以前那样分开调用，这会完全影响你的对象结构。你将不得不放弃小粒度对象和小粒度方法带来的清晰意图和小粒度控制所带来的好处。编程变得困难，并且会使生产率下降。</原文结束> 分布式对象意味着粗粒度的调用。Ajax 是一个例子，跟前端工程师协作时，总是尽可能地把尽可能多的数据塞到一个响应里。 <原文开始>一个远程外观是一个粗粒度的外观（facade），它建立在大量的细粒度对象之上。所有细粒度对象都没有远程接口，并且远程外观不包括领域逻辑。远程外观所要完成的功能是把粗粒度的方法转换到低层的细粒度对象上。</原文结束> <原文开始>任何外观都应该是一层薄薄的皮肤并且只负责很小一部分责任。</原文结束> 对 RESTful 服务而言，Facade 对应着 Controller 这一层。 <原文开始>远程外观这种模式意味着同步。</原文结束> ## 通盘考虑 <原文开始>.NET 大力宣传的是 Web Services，但是我不会在一个应用程序内部使用 Web Services，而只会像在 Java 中一样，使用它们作为一种允许应用集成的表现层。</原文结束> <原文开始>在我撰写本书时，专家们关于 Web Services 比较一致的观点是：它使得重用成为现实，并最终导致系统集成商的消失。但是我对此持谨慎态度。Web Services 在本书介绍的这些模式中发挥不了太大的作用，因为 Web Services 是应用集成而不是应用构建的技术。</原文结束> ## 分布策略 <原文开始>细粒度接口不能很好地用在远程调用中。.... 当在多个类上应用分布式策略时，最终得到的系统有许多的远程调用，从而需要繁琐的粗粒度接口。</原文结束> 因为远程调用的成本，人们倾向于希望在一次调用中完成更多的事情，导致远程调用的接口变得臃肿不堪。 <原文开始>分布式对象设计第一定律：不要分布使用对象。</原文结束> <原文开始>在设计系统时必须尽可能限制分布边界。... 最困难的地方在于：要保证结果不会产生太多的远程调用。</原文结束> <原文开始>我认为在 Web Service 中更适合使用异步方式。</原文结束> ## 第二章 <原文开始>ActiveRecord 就是从行数据入口开始，把领域逻辑加到类中。</原文结束> rails 的 ActiveRecord 和 DataMapper 两个 ORM 在模式层面其实区别不大，后者并没有反映 DataMapper 模式的样子，把业务逻辑加到 DataMapper 的子类的话，还是 ActiveRecord 模式。 django 自带的 ORM 更像 DataMapper 模式一些？ <原文开始>关系数据库的映射开销大概是程序开发总开销的 1/3。</原文结束> <原文开始>现代的系统允许把引用完整性检查延迟到交互结束的时候进行。如果有这个能力，没有道理不使用它。</原文结束> ## 分层 <原文开始>层次并不能封装所有东西，有时它会为我们带来级联修改。</原文结束> <原文开始>20世纪90年代，随着 C/S 系统的出现，分层的概念更明显了... 问题来自领域逻辑：如业务规则、验证、计算等。通常，人们会把它们写在客户端，但是这样很笨拙，并且往往把领域逻辑直接嵌入到用户界面。... 另一种办法是把这些领域逻辑放到数据库端，作为存储过程。</原文结束> MVC 式的分层是面向对象的产物。在 C/S 时代，Client 直接操作控件里的数据源，数据源映射到后端的数据库。现在的同学应该很难分辨哪些关系式数据库的 feature 是 C/S 时代的遗留了。 <原文开始>当人们讨论分层时，常常不容易区分 layer 和 tier。... tier 意味着物理上的分离。客户/服务器系统通常被称为 "Two Tier System。"</原文结束> <原文开始>以下因素被 Jens Coldewey 称为复杂性增压器（Complexity Booster）：分布、显式多线程、范型差异（例如对象/关系）、多平台开发以及极限性能要求。</原文结束> ## 引言 <原文开始>他认为，架构是一种主观上的东西，是专家级项目开发人员对系统设计的一些可共享的理解。</原文结束> <原文开始>即使是某个企业统一了集成技术，它们也还是会遇到业务过程中的差异以及数据概念的不一致性。</原文结束> <原文开始>我认为“业务逻辑”这个词很滑稽，因为很难再找出什么东西比“业务逻辑”更加没有逻辑。</原文结束> <原文开始>在文件拷贝过程中，为用户提供一个“进度条”，将会提高用户界面的响应性，但并不会提高响应时间。</原文结束>