企业应用架构模式的笔记(34)

我来写笔记

按有用程度 按页码先后 最新笔记

展开收起
远程外观 (Remote Facade)

红色有角F叔 (勇敢困难不怕牛牛)

任何对象可能作为远程对象使用时，经常需要一个粗粒度的接口来减少完成某些任务所需要的调用次数。这不仅会影响你的方法调用，同样还会影响你的对象。现在，一个调用中就会包括访问和更改订单及订单的功能，而不会像以前那样分开调用，这会完全影响你的对象结构。你将不得不放弃小粒度对象和小粒度方法带来的清晰意图和小粒度控制所带来的好处。编程变得困难，并且会使生产率下降。分布式对象意味着粗粒度的调用。Ajax 是一个...
2014-08-05 22:30:49
展开收起
远程外观(Remote Facade)

红色有角F叔 (勇敢困难不怕牛牛)

我更倾向于粗粒度的结构和较少的远程外观。对于远程外观而言，最大的错误之一就是把领域逻辑放在其中。我再三强调：“远程外观没有领域逻辑。”任何外观都应该是一层薄薄的皮肤并且只负责很小一部分责任。
2015-10-23 22:36:34
展开收起
离线乐观锁

红色有角F叔 (勇敢困难不怕牛牛)

应该在任何系统的业务事务冲突中优先考虑（乐观锁）。悲观锁可以作为乐观锁的补充，因此不要考虑何时使用乐观锁，而应该考虑什么情况下光有乐观锁还不够。
2014-08-06 22:15:16
展开收起
数据传输对象(Data Transfer Object)

红色有角F叔 (勇敢困难不怕牛牛)

很多方面，数据传输对象都是我们被告知永远不要写的对象之一。它经常只不过是一堆字段及它们的 getter 和 setter 方法。这种对象的价值在于允许你在一次调用中传输几部分的信息，这是分布式系统的本质。 Form Object 也可以算是一种 DTO 吧。数据传输对象的常见格式是记录集。... 记录集就是一个为 SQL 数据库服务的数据传输对象。序列化的一个重要用因素是连接双方的数据传输对象的同步。从理论上说，无论何时服务器改变了数...
2014-08-05 22:37:56
展开收起
通盘考虑

红色有角F叔 (勇敢困难不怕牛牛)

.NET 大力宣传的是 Web Services，但是我不会在一个应用程序内部使用 Web Services，而只会像在 Java 中一样，使用它们作为一种允许应用集成的表现层。在我撰写本书时，专家们关于 Web Services 比较一致的观点是：它使得重用成为现实，并最终导致系统集成商的消失。但是我对此持谨慎态度。Web Services 在本书介绍的这些模式中发挥不了太大的作用，因为 Web Services 是应用集成而不是应用构建的技术。
2014-07-24 23:36:23
展开收起
分布策略

红色有角F叔 (勇敢困难不怕牛牛)

细粒度接口不能很好地用在远程调用中。.... 当在多个类上应用分布式策略时，最终得到的系统有许多的远程调用，从而需要繁琐的粗粒度接口。因为远程调用的成本，人们倾向于希望在一次调用中完成更多的事情，导致远程调用的接口变得臃肿不堪。分布式对象设计第一定律：不要分布使用对象。在设计系统时必须尽可能限制分布边界。... 最困难的地方在于：要保证结果不会产生太多的远程调用。我认为在 Web Service 中更适合使用异...
2014-07-24 23:32:50
展开收起
第二章

红色有角F叔 (勇敢困难不怕牛牛)

ActiveRecord 就是从行数据入口开始，把领域逻辑加到类中。 rails 的 ActiveRecord 和 DataMapper 两个 ORM 在模式层面其实区别不大，后者并没有反映 DataMapper 模式的样子，把业务逻辑加到 DataMapper 的子类的话，还是 ActiveRecord 模式。 django 自带的 ORM 更像 DataMapper 模式一些？关系数据库的映射开销大概是程序开发总开销的 1/3。现代的系统允许把引用完整性检查延迟到交互结束的时候进行。如果有这个能力，没有...
2014-07-24 23:27:33
展开收起
分层

红色有角F叔 (勇敢困难不怕牛牛)

层次并不能封装所有东西，有时它会为我们带来级联修改。 20世纪90年代，随着 C/S 系统的出现，分层的概念更明显了... 问题来自领域逻辑：如业务规则、验证、计算等。通常，人们会把它们写在客户端，但是这样很笨拙，并且往往把领域逻辑直接嵌入到用户界面。... 另一种办法是把这些领域逻辑放到数据库端，作为存储过程。 MVC 式的分层是面向对象的产物。在 C/S 时代，Client 直接操作控件里的数据源，数据源映射到后端的数据库。...
2014-07-21 21:49:55
展开收起
引言

红色有角F叔 (勇敢困难不怕牛牛)

他认为，架构是一种主观上的东西，是专家级项目开发人员对系统设计的一些可共享的理解。即使是某个企业统一了集成技术，它们也还是会遇到业务过程中的差异以及数据概念的不一致性。我认为“业务逻辑”这个词很滑稽，因为很难再找出什么东西比“业务逻辑”更加没有逻辑。在文件拷贝过程中，为用户提供一个“进度条”，将会提高用户界面的响应性，但并不会提高响应时间。
2014-07-21 21:47:20
展开收起
第94页

ZFenng (追求技术又学习管理的IT人)

服务层有两个作用，一是划定了应用的边界，以使之和客户端及其它外部调用的系统分离。二是封装了服务应当逻辑。业务逻辑一般分为“领域逻辑”及“应用逻辑”。前者只与问题领域相关，但后者与应用和工作流程有关。应用逻辑不适合全部放入领域模型对象中，因为这不利于领域模型对象的重用。如果将来需要重现此工作流，则要引用当前应用的领域模型，与需要构筑的应用的领域模型冲突。当服务层不包含应用逻辑时，其仅为外观模式...
2013-08-26 14:29:46