DAL 设计和指导

Question

我需要一些有关创建 DAL 的指导。我试图找到一些好的资源，但没有找到任何符合我需求的东西。

我有一个稍微复杂的数据库布局，其中包含几个一对多关系和一个多对多关系。我在网上看到的大多数文章都可以参考实体框架来帮助使用 ORM，但不幸的是我不能使用它，因为我不能使用反射/发射

目前，我有一个类完全代表我的数据库中的每个表。然后我有一个通用存储库，所以我可以操作这些类。最重要的是，我还有一个手动实现关系的层（服务层？？），即一个客户可能有多个地址，因此一个客户对象将有一个地址列表。这是执行计算/操作的层。当对这些关系对象之一进行更改时，服务层会处理转换为表对象并通过存储库提交更新。

几个问题：

1. 层的技术名称是什么？
2. 表表示是否称为 DTO，关系对象是否称为 POCO？
3. 应该在存储库中完成从关系对象到表对象的转换，我称之为服务层，还是中间步骤？
4. 最后，我所做的有意义吗？

非常感谢任何指向适用文章的链接。

对缺少代码表示歉意。当我下次使用计算机时，将更新示例。

编辑：要明确的是，这是针对本地 sqlite 数据库的 windows phone 和 winrt。我正在使用一个简单的 orm 将一个表映射到一个对象，但是，如果没有发出，我无法自动生成复杂的对象，因此我不得不在简单的表表示上创建另一个层来解决这个问题。

问候

Answer 1

我有一个稍微复杂的数据库布局，其中包含几个一对多关系和一个多对多关系。

啊，我有一个稍微复杂的菜单要煮。鸡蛋和培根。

见过稍微复杂的数据库吗？假设有 200 个表格，也许有 600 个关系？请。几个一对多和一对多是什么 - 但并不复杂。

我看过在线参考实体框架来帮助处理 ORM，但不幸的是我不能使用它，因为我不能 使用反射/发射

鉴于 .NET 框架中包含了一个稍微过时的实体框架版本 - 因此安装在 GAC 中并绕过了安全性 - 为什么你认为它神奇地不能使用反射或发射？

现在回答：

1：无。那些不是层。这一切都是ORM。我将它们称为数据访问层和对象管理层。

2：仅当它们是退化的业务对象时才称为 DTO - 没有逻辑（业务，而不是数据访问）。否则显然它们不是数据访问对象。现在 poco - 你甚至知道这个词是什么意思吗？普通的旧 C# 对象 - 即不从基类继承。

3：视情况而定。

4：没有。你不使用反射/发射的论点很弱 - 这是一个温和的说法。你在你的头上。我确实维护了一段时间的商业 ORM，在我一生中所做的所有事情中，这可能是最复杂的软件。有很多错误，恕我直言，你太胖了，不能这样做，并且可能会做一个非常糟糕的案例，并花费大量时间试图解决其他人已经解决的问题 - 没有任何实际收益。动态的 sql 生成会给你白头发，或者只能处理非常基本的元素。你最好花时间找出为什么不能使用反射或发射字节码....

文章....嗯。仍然是我的参考手册：Scott Ambler 的“Building Object Applications That Work”——我相信您可以在 Internet 上找到它，例如在 amazon。