ariestse9的博客

解决这种表现问题的方法是：通过对象中的一个标识域来保持咩哥对象的关系特性，并且通过查找这些值来保持对象引用和关系键之间的相互映射，从硬盘中读取数据的时候，使用标识映射作为从关系键到对象的查找表，每次使用表中的外键，都用外键映射来得到合适的对象间引用，如果标识映射中没有该键值，就需要到数据库中读取它或使用延迟加载。在这个基础上，集合的处理需要更复杂的外键映射版本，如果对象包含一个集合，则必须构造一个新的查询来找到所有与源对象的ID相关的行(也可以用延迟加载来避免查询)，创建每个返回的对象并加入到集合中。

每一个模式描述了在我们身边不断出现的问题以及该问题解决方案的核心。模式的关键点是它们源于实践，必须观察人们的工作过程，发现其中好的设计，并找出“这些解决方案的核心”

当用分层的观点来考虑系统时，可以将各个子系统想象成按照“多层蛋糕”的形式来组织。每一层都依托在其下层之上。在这种组织方式下，上层使用了下层的各种服务，而下层对上层一无所知。另外，每一层对自己的上层隐藏其下层的细节。（当然，并非所有的分层架构都这么隔绝，但绝大多数时不透明的，或至少是几乎不透明的）分层的特点也是重点是下层对上层一无所知，每一层对自己的上层隐藏了其下层的细节。

领域逻辑的组织可以改分为三种主要的模式：事务脚本、领域模型以及表模块。

首先介绍的一组模式时架构模式，它要解决的问题时驱动领域逻辑访问数据库的方式，此时的选择对于设计影响深远，而且难以重构，因此这个问题需要注意。同样，如何设计领域逻辑也会对这个选择产生重大的影响。尽管SQL已经在商业软件中广泛应用，但它在使用中还是存在一些缺陷，许多应用程序开发者并不能充分理解SQL，因此，不能很好的构造有效的查询语句和命令。基于这些原因，把SQL访问从领域逻辑中分离出来，并把它放到独立的类中，实在是明智之举。

用基于行的类可以使查找变成静态操作，但这样就不能通过服务桩在测试的时候调换数据库，为了避免这个问题，最好创建独立的查找器对象，每一个查找器类都封装了很多SQL语句的方法，当执行查找操作的时候，返回一个适当的基于行的对象集合。使用查找器方法要注意的是：这些查找器方法工作在数据库状态下，而不是对象状态下，如果发出一个对数据库的查询，找到一个俱乐部内的所有人，那么任何你在内存中加入的对象都不在其中，解决的方法是一开始就进行查询。另一个避免多次进入数据库的方式是使用连接(Join)，这样就可以一次查询多张表。