任何一个都可以使用(Fowler's POEAA): 数据源架构模式: 表数据网关:作为数据库表的网关的对象。一个实例处理表中的所有行。 行数据网关:作为数据源中单个记录的网关的对象。每行有一个实例。 活动记录:包装数据库表或视图中的一行的对象,封装数据库访问,并在该数据上添加领域逻辑。 数据映射器:一层映射器,将数据在对象和数据库之间移动,同时使它们彼此独立以及与映射器本身独立。 选择哪个取决于您选择了哪个(同一来源): 领域逻辑模式: 事务脚本:按照过程组织业务逻辑,每个过程处理来自演示的单个请求 领域模型:包含行为和数据的领域的对象模型 表模块:处理数据库表或视图中所有行的业务逻辑的单个实例。 服务层:定义应用程序的边界,通过一层服务建立一组可用操作,并协调每个操作的应用程序响应。 通常情况下,如果您的业务对象越接近DB模式并围绕CRUD操作,那么您的数据源架构和领域逻辑模式就越简单(但不必如此)。如果您发现自己存在大量阻抗不匹配或与DB数据无直接关系的业务逻辑,则可以选择领域模型/数据映射器(还可以包括ORM)。
有几种方法可以处理这个问题,但我想推荐的是将DataMapper模式与领域模型相结合。更多信息请参见此页面。这样,您可以以良好且简单的方式将数据访问与领域模型(业务逻辑)分离开来。如果您对面向对象编程略有了解,则上面链接的UML模型应该能够澄清处理方式以及如何将数据库逻辑与业务逻辑分离的方式。