注：上图只是为了表达清晰 ， 省略了领域层 ， 实际上 ， “查询通道”只是一个概念 ， 在实际设计中 ， 会把查询方法都封装在领 。

32、域对象仓库接口中 ， 实现放在领域对象仓库实现中 ， 所以 ， 应用服务层还是通过调用领域层的领域对象仓库查询接口完成查询业务的 。
补充说明：DTO即数据传输对象 ， 它只包含数据 ， 没有任何行为 ， 同时 ， DTO把DO的对象关联关系辗平 ， 成为一个独立的数据视图对象 ， 以房间DTO为例 ， 它不会关联到楼层、分期等DTO ， 而是把楼层名、分期名作为房间DTO的一个属性 ， 这种设计方式通常称为“贫血模式” ， 也相当于Martin Fowler在企业应用架构模式一书中所说的“事务脚本（Transaction Script）”模式 。
另外 ， 对于一些变化频率很低或者不会发生变化的数据 ， 如很多页面的下拉菜单数据等 ， 为了减轻数据库服务的IO压 。

33、力 ， 还需要采取缓存策略 。
5.1.3 创建订单典型的高并发资源争用业务分析：创建订单是整个系统一个非常重要的业务功能 ， 它在一些特定的时间 ， 如五一、十一等开发商促销的时间并发性比较高 ， 由于同一个房间在同一时间只能下一张订单 ， 这里就涉及一个在下订高峰期房间争订的情况 ， 系统要保证不要出现同一房间被不同两个客户下订的情况 。
根据创建订单的业务规则 ， 订单只能预订状态为“可售”的房间 ， 当下订成功后 ， 房间状态被改变为“已售” ， 要保证不出现上述争订的情况 ， 事实上就是要保证在整个订单创建过程房间状态数据变化的排它性 。
决策：由于系统使用Hibernate作为持久化框架 ， 我们可以利用Hibernate提供的为数据库相关 。

34、数据上“锁”的功能来保证数据变化的排它性 。
Hibernate提供了两种数据锁定机制：悲观锁和乐观锁 。
悲观锁对数据的处理采取一种保守的策略 ， 即在整个数据处理过程（完整的事务）中 ， 对目标数据上锁 ， 以保证事务以外的其他操作都无法在此事务提交前对目标数据进行修改 ， 悲观锁的实现通常依赖于数据库提供的锁机制 。
乐观锁采取比悲观锁相对宽松的策略 ， 它的原理是 ， 为数据增加一个用于记录“版本”的字段 ， 当事务读取数据时 ， 会把数据的版本号也一并读取 ， 当事务修改了数据后 ， Hibernate会自动把该数据的版本号加1 ， 然后在提交事务前 ， 把该版本号与数据库中的对应数据的版本号进行对比 ， 如果该版本号高于数据库记录的版本号 ， 证明 。

35、在事务过程中没有其他事务修改并提交过对应数据 ， 事务被提交；如果该版本号不高于数据库记录的版本号 ， 则说明事务过程中已经有其他事务修改了该数据并提交 ， 事务提交被拒绝 。
对比两种策略 ， 我们发现 ， 两种策略达到的效果是一致的 ， 但悲观锁更加严谨 ， 保证先开启的事务对数据有主动权 ， 但同时 ， 它却带来了数据库性能的大量开销 ， 因为在整个事务过程中 ， 所有其他事务都无法修改被锁定的数据 ， 尤其对于长事务 ， 这种开销更加明显 。
乐观锁不能保证先开启的事务对数据占有主动权 ， 实际上是先提交的事务才会被成功提交 ， 但乐观锁基本不会浪费数据库的性能开销 ， 而且不依赖于数据库的锁机制实现 。
创建订单是一种高并发的操作 ， 每个房间在整个下订过程只被 。

36、一个客户占有 ， 这显然是客户不能接受的 ， 而事务孰先孰后 ， 对于客户来讲却是透明的 ， 很明显 ， 我们应该采用Hibernate的乐观锁策略来避免房间争订的情况 。
创建订单只不过是整个系统的其中一个典型的功能点 ， 对于其他类似的功能 ， 如财务收退款这些敏感操作 ， 我们都需要采用相同的策略对数据进行锁定处理 。
5.1.4 数据权限控制SaaS RES 1.0在客户管理、销售管理、服务管理、财务管理和报表等模块中都有数据权限控制的需求 ， 数据权限控制的意思是：不同角色可以拥有同一个系统功能的使用权限 ， 但不同角色对于同一系统功能 ， 其操作的数据是有可能不同的 。
目前系统定义了三个级别的数据权限：l 全部：对应功能权限能操作所有 。

【SaaS|SaaS RES营销管理系统架构设计】37、相关数据；l 本人管辖的员工负责的数据：对应功能权限只能操作当前用户拥有的数据 ， 以及当前用户所在部门（包括下级部门）的所有员工所拥有的数据；l 本人负责的数据：对应功能权限只能操作当前用户拥有的数据 。

稿源：(未知)

【傻大方】网址：/a/2021/0902/0024073868.html

标题：SaaS|SaaS RES营销管理系统架构设计( 六 )