直接从数据库查询构建的业务对象答案

【问题标题】：Business objects built up directly from a database query直接从数据库查询构建的业务对象
【发布时间】：2011-03-16 03:19:54
【问题描述】：

...它叫什么？

更详细：对于我的应用程序，我创建了一个很好的业务模型来作为内存对象使用。它与存储和视图无关。现在，对于存储层，有一个数据库：我将构建 SQL 查询（越少越好），从相关表中选择/连接等所有我需要的数据。一种“中间层”获取查询结果并构造具有所有关系的业务对象。

问题：您如何称呼这种方法？最佳做法是什么？

这发生在 .NET C# 项目中，但这与此设计问题无关。

（我发现问题 441532 非常相似，但我对更多设计输入感兴趣）

注意：我不采用 ORM 方法依赖于自动执行此操作的工具，因为该应用程序只需要从相对较大的数据库中选择的数据。

【问题讨论】：

标签： database data-access-layer business-objects

【解决方案1】：

我认为它被称为 ORM，或对象关系映射。

NHibernate 就是这样一个例子。

【讨论】：

不，我不是在构建一个 1:1 的数据库层（一个表一个类）。我想从几个（连接）SQL 查询中获得的行直接构建我的业务对象。我完全跳过了 ORM 方法。
如果你在数据库中有数据并且想在域对象中使用它，你正在做 ORM。可以称为行数据网关、表数据网关、活动记录、数据映射器、DAO 等。
ORM 并不意味着每个类一个表。而且我认为您倒退了：您要么从现有模式生成对象，要么创建域模型，然后创建表。从您决定编写的任何查询中创建任意对象完全是另一种动物。
好吧，你是对的。所以它是一种ORM。这是我正在采取的好方法吗？非常感谢这里的所有输入，谢谢。

【解决方案2】：

通常称为 DDD - 领域驱动设计。

https://stackoverflow.com/questions/tagged/ddd

https://stackoverflow.com/questions/tagged/domain-driven-design

【讨论】：

【解决方案3】：

有不同的 ORM 工具。 Linq to SQL 做 1:1，这不是你想要的。

您所说的与Domain Driven Design 重叠，您的设计是由域驱动的，而不是由数据库驱动的。

在这种情况下，如果您使用的是关系数据库，您仍然需要一个 ORM，而 Entity Framework 和 NHibernate 等 ORM 允许您以任何您想要的方式灵活地将实体“映射”到您的数据库，其方式是，如果您的数据库因任何原因需要更改，或者您的实体必须更改，无论出于何种原因，您只需要更改中间的“映射”层。

看看fluent nhibernate

【讨论】：