c# - LINQ to SQL 体系结构。什么是最好的？

Question

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

可能性是:

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

优点:

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

缺点:

• 对象必须被复制，如果相关，造成维护 hell
• 对象不能在上下文之间传递，因此需要对数据库进行另一次访问

单一数据上下文:所有表、 View 、过程都位于同一个巨大的上下文中。

优点:

• 无重复
• 关系很容易管理，基本上 LINQ 会处理它。
• 更好的性能，更少的数据库命中。

缺点:

• 所有表都在同一个命名空间中，代码完成变得很疯狂
• 对设计者来说不是最好的(至少在 VS2008 上)
• 不能选择保存什么和不保存什么。全部保存或删除所有模式。

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

谢谢大家

Answer 1

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

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

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

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

最后我意识到，使用 LinqToSql 的最佳方式是将上下文当作简单的 DAL。重用其域，并进行一些扩展(我们可以使用 T4 来帮助我们创建代码)，其中实体被转换为 DTO(数据传输对象)以将数据公开给其他层。

我将在我的博客中发布(尚未完成)我在练习中采取的步骤:http://developmentnirvana.blogspot.com/