LINQ to SQL 架构。什么是最好的？答案

【问题标题】：LINQ to SQL architecture. What is best?LINQ to SQL 架构。什么是最好的？
【发布时间】：2010-11-04 12:56:01
【问题描述】：

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

可能性是：

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

优点：

易于使用
类将被分成不同的命名空间
要维护的域更小

缺点：

如果出现以下情况，则必须复制对象相关，创造维护地狱
无法在上下文之间传递对象，因此需要再次访问数据库

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

优点：

没有重复
关系易于管理，基本上由 LINQ 处理。
性能更好，对 DB 的访问更少。

缺点：

所有表都在同一个命名空间中，代码完成变得疯狂
对设计师来说不是最好的（至少在 VS2008 上）
无法选择要保存和不保存的内容。全部保存或删除所有模式。

嗯，这是我想到的事情，所以如果有任何其他优点或缺点，请告诉我，我会将它们包含在帖子中。也选择你最好的。

谢谢大家

【问题讨论】：

另外，EF - 但高度相关：stackoverflow.com/questions/1028739/…

标签： c# .net vb.net linq-to-sql architecture

【解决方案1】：

我理解你的疑虑。当我开始使用 LinqToSql 时，我也遇到了同样的情况。为了帮助我找到更好的方法，我开始创建一个个人项目，我可以在其中测试所有方法而无需担心和成见。

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

我在练习中意识到的另一个方面是直接使用 LinqToSql 在组织方面效率不高。如果您有一个项目，其中一个团队将执行开发而不是一个人，您应该“屏蔽”LinqToSql 免受他们的影响。应该有一个“治安官”来处理这个领域，你还应该使用一些抽象机制来保护模型不被滥用（我实现了一个存储库模式，它运行良好，但你可以找到不同的方法）。

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

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

我将在我的博客中发布（尚未完成）我在练习期间采取的步骤：http://developmentnirvana.blogspot.com/

【讨论】：

【解决方案2】：

在我看来，数据上下文直接隐藏在存储库接口后面——允许我们根据需要交换实现（LINQ-to-SQL / EF / NHibernate / LLBLGen / 等）。因此，数据上下文的细节很大程度上是实现细节。只要它通过了单元测试；-p

巨大很少是一个好主意； tiny 很少有用...我倾向于将系统分解为相关的块（通常与不同的存储库接口相关），并在该级别上考虑它。我在这里还有一些其他想法：Pragmatic LINQ - 虽然我很乐意听从Frans 等的任何智慧。

【讨论】：

【解决方案3】：

关于使用 LINQ to SQL，还有两点需要考虑：

虽然它并未过时，但 Microsoft 已表示未来开发的重点将是实体框架，而不是 LINQ to SQL
LINQ to SQL 将您直接与数据库的结构联系起来。如果您使用实体框架，您将能够以独立于您的数据库实现的方式设计您的实体。例如，如果您决定将一个实体拆分为两个表，您的调用者将不需要知道。

【讨论】：

我说的是“不会过时”，“未来发展的重点是EF”。
实际上，EF是微软推荐的，但L2S会根据需要进行开发和升级。看看上个月的 VS 杂志。
@Oakcool：这不是我说的吗？略有不同 - 必要时升级可能并不意味着新功能。

【解决方案4】：

所以在多上下文下进行了大约一年的开发后，我了解到使用多上下文不是一个好主意，当您的表应该真正存在于 2 个或更多上下文中时，问题就来了，通常是多到很多关系。会发生的情况是，中间只能在其他 2 个表插入记录时插入记录，因此如果您像其他事务一样使用 L2S，则将首先创建该记录，FK 等于 0 (零），那是无效的（参照完整性），这会导致错误。这是我发现的不便之处之一，但如果需要，我可以列出更多。现在我使用的解决方案是创建一个“调度程序”，这家伙负责等待满足某些条件（父母双方都有一个有效的ID，不同的是0（零）），然后它插入，这很通常允许我需要尽可能多的专业化（我有 6 个上下文），它使用 PropertyChanged 事件来通知调度程序的更改。

所以这篇文章中最重要的是，使用单一上下文，如果你不喜欢头痛（我一点也不）。说了这么多，有人可能会问，为什么我要继续使用多个上下文，好吧，可以说这是我上面的决定，我没有反击的力量。（虽然我真的很努力，很努力）

【讨论】：