LINQ to SQL架构。哪种是最好的？

Question

这个问题有点像调查。我们试图在使用像LINQ to SQL这样的ORM时找到最佳架构。我们正在定义一种框架，其他应用程序将通过直接引用DLL或通过Web服务访问它。我们有.NET应用程序和PHP应用程序。

可能性如下：

多个数据上下文：将数据库分成工作单元，并为每个工作单元创建单独的上下文。

优点： -易于使用 -类将被分解为不同的命名空间 -更小的领域需要维护

缺点： -如果相关，则必须复制对象，导致维护困难 -无法在上下文之间传递对象，需要再次访问数据库

单个数据上下文：所有表、视图、过程都驻留在同一个巨大的上下文中。

优点： -没有重复 -关系易于管理，基本上是由LINQ处理的。 -性能更好，对数据库的访问量更少。

缺点： -所有表都在同一个命名空间中，代码完成变得混乱 -不适合设计师（至少在VS2008中） -不能选择保存什么和不保存什么。只能保存全部或删除全部。

这些是我想到的事情，如果您有任何其他优点或缺点，请告诉我，我会在帖子中包含它们。同时请选出您最喜欢的。

谢谢大家。

- Oakcool

---

此外，EF - 但高度相关：https://dev59.com/hEjSa4cB1Zd3GeqPChy4 - Marc Gravell

Answer 1

我理解你的疑虑。当我开始使用LinqToSql时，我也有同样的疑虑。为了帮助我找到更好的方法，我开始创建一个个人项目，在其中可以测试所有方法，没有担心和先入为主的想法。

在这个练习中，我发现只有一个上下文方法是最有用的。这种解决方案似乎更容易维护，如果需要重新创建域，您只需在一个项目中管理一个文件。

我在练习中意识到的另一个方面是，直接使用LinqToSql在组织方面并不高效。如果您有一个团队将执行开发的项目，而不仅仅是一个人，您应该将LinqToSql“保护”起来。应该有一个“警长”来处理域，您还应该使用一些抽象机制来保护模型免受滥用（我实现了存储库模式，它工作得很好，但您可能会找到不同的方法）。

我也面临着在领域内创建一些逻辑组的问题。实际上，我使用了一些DDD（领域驱动设计）技术来创建所谓的聚合体。聚合体是领域内实体的逻辑排列，其中有一个根实体（作为聚合器）和其他几个卫星实体相互关联。您可以通过在LinqToSql域中创建一些新实体来实现此目的。这些新实体将与数据库断开连接，并作为聚合器工作。这种方法将使您能够在您的领域内创建“子域”，并帮助您拥有更好的设计。

最终，我意识到使用LinqToSql的最佳方法是将上下文视为简单的DAL。重用其领域，带有一些扩展（我们可以使用T4来帮助我们创建代码），其中实体被转换为DTO（数据传输对象）以将数据暴露给其他层。

我正在发布（尚未完成）我在博客中进行的练习步骤：http://developmentnirvana.blogspot.com/

- GRGodoi

Answer 2

在我看来，数据上下文(data-context)在仓储接口(repository interface)的后面进行了隐藏，这样我们就可以随时替换实现(如LINQ-to-SQL / EF / NHibernate / LLBLGen等)。因此，数据上下文的细节很大程度上是一个实现细节。只要它通过了单元测试；-p 通常庞大的系统很少是一个好主意;微小的系统也很少有用... 我倾向于将系统分解为相关的块(通常与不同的仓储接口相关)，并以那个级别考虑它。我在这里有一些其他的想法：实用的LINQ - 尽管我很乐意接受Frans等人的任何建议。

- Marc Gravell

Answer 3

使用LINQ to SQL还有两个需要考虑的问题：

1. 虽然它并不过时，但微软已经声明未来的开发重点将是Entity Framework而不是LINQ to SQL。
2. LINQ to SQL直接绑定数据库结构。如果您使用Entity Framework，您将能够以与数据库实现无关的方式设计实体。例如，如果您决定将一个实体拆分成两个表，您的调用者将不需要知道。

- John Saunders

---

我所说的是“不过时”，而且“未来发展的重点将是EF”。 - John Saunders

实际上发生的是EF是微软推荐的，但L2S将会根据需要进行开发和升级。 看看上个月的VS Magazine。 - Oakcool

@Oakcool：这不就是我说的吗？稍有不同的是，“根据需要升级”可能并不意味着有新功能。 - John Saunders

Answer 4

经过大约一年的开发，我发现使用多个上下文并不是一个好主意，当你有一个应该存在于两个或更多上下文中的表格时，问题就会出现，通常是一个多对多的关系。

问题在于，在其他两个表格插入记录之前，中间表格只能插入一条记录。如果像处理其他事项一样使用L2S，那么该记录将首先被创建，并且外键等于0（零），这是无效的（引用完整性），从而导致错误。

这是我发现的其中一个缺点，但如果需要，我还可以列举出更多缺点。

现在我使用的解决方案是创建一个“调度程序”，这个调度程序负责等待特定条件满足（两个父级具有有效ID，而不是0（零）），然后进行插入操作。此操作非常通用，以允许我需要尽可能多的专业化（我有6个上下文），并且使用PropertyChanged事件作为一种向调度程序通知更改的方式。

所以，这篇文章中最重要的事情是使用单一上下文，如果你不想头疼的话（我完全不想）。然而，所有这些说完之后，有人可能会问：为什么我还在坚持多个上下文呢？嗯，让我们称之为来自我的上级的决定，而我没有任何反击的能力。（尽管我真的很努力地尝试了）

- Oakcool