LINQ to SQL 数据访问层 + 业务逻辑层 + 表现层

Question

我有一个简单应用的设置如下：

1. 从数据库表中生成了 LINQ to SQL 类（数据访问层？）； 2. 创建了使用 LINQ to SQL 数据上下文的类（业务逻辑层？），用来插入、更新、删除、选择； 3. 在我的表示层，例如插入一个新的“产品”，我正在创建来自 DAL 层的对象“Product”的新实例（这是 LINQ to SQL 为我创建的）。

我的问题是，如果在这种情况下这样做是正确的分层方式。奇怪的是，我正在使用在 DAL 中定义的对象类型，在我的表示层中不应该使用它。但是，如果我想利用 LINQ to SQL 对象而不再创建新对象，这似乎是正确的方法。

你对此有何建议？我不确定最佳方法是什么。

- Jorre

Answer 1

我认为不存在一种适合所有情况的解决方案，但如果你有一个简单的应用程序，你可能不想不必要地复杂化问题。如果你能忍受在演示层保持数据上下文开放，在保持 L2SQL 实体方面有一些“生产力”收益：

• 支持延迟加载（但要注意 1:N 问题）
• 你有一个单一的生成实体集合（尽管感知数据上下文）

然而，对于更重的、更纯粹的架构，你可以考虑……

• 使用仓储模式包装Linq2SQL工件
• 在将它们返回到您的BLL / Service层之前，将L2SQL实体映射为POCOs
• 根据您的网络和表示架构，您还需要考虑实体在网络上的样子（序列化、WCF、JSON等），您可能还需要查看视图模型, 在这种情况下，您的实体会在各个层次之间映射和转换时多次“更改”类和形状。
• 实际上，您可以考虑使用其他ORM，如NH或EF，而不是Linq2SQL

编辑： 如果您不希望在BLL或Presentation层中使用VS生成的L2SQL实体，则有几个选项可供选择。

• 创建一个新的POCO集合，然后在您的仓库/ dal中映射L2SQL实体。 Automapper可以简化此任务。

• 您可以通过提供XmlMappingSource直接在Linq2SQL中使用自己的POCO，尽管这需要更多的工作。

- StuartLC

---

谢谢你的帮助。我对 Linq 2 SQL 的易用性感到非常满意，所以我想继续使用它，但我的唯一担忧是我在演示层中使用了 DAL 实体。在我的当前设置中，最简单的解决方法是什么？ - Jorre