c# - 数据库中有 1000 多个 Linq 查询或逻辑……哪个更糟？

Question

我曾在 much more long-winded way a few days ago 中问过这个问题，考虑到篇幅，我没有得到答案这一事实不足为奇，所以我想我应该更切题。

我必须根据用户对特定客户的分配来决定向他们显示什么。域对象看起来像这个大大简化的示例:

public class Customer
{
    public string Name { get; set; }
    public IEnumerable<Users> AssignedUsers { get; set; }
}

在现实世界中，我还将评估他们是否有权限(对安全标志使用按位比较)来查看这个特定的客户，即使他们没有直接分配给它也是如此。

我正在努力坚持 domain-driven design (DDD) 原则在这里。此外，我正在使用 LINQ to SQL 进行数据访问。在我的服务层，我为请求客户列表的用户提供服务，该列表目前大约有 1000 项，并且每月增长约 2%。

如果我严格要求在服务层保留逻辑，我将需要使用 Linq 执行一个 .Where 来评估 AssignedUsers 列表是否包含请求的用户列表。当系统枚举通过时，这将导致对每个 Customer 的级联查询。我没有做过任何测试，但这似乎效率不高。

如果我捏造数据中的无逻辑，那么我可以简单地使用 GetCustomersByUser() 方法来执行 EXISTS 类型的 SQL同时查询和评估安全性。这肯定会更快，但现在我谈论的是逻辑逐渐进入数据库，这可能会在以后产生问题。

我敢肯定，这是人们在推出 Linq 时提出的一个常见问题……关于哪种方法更好有什么建议吗？ Linq 的多个查询对性能的影响是否优于我数据库中的逻辑？

Answer 1

哪个更糟？ 取决于你问谁。

如果您问 DDD 极端纯粹主义者，他们可能会说数据库中的逻辑更糟糕。

恕我直言，如果您问几乎任何其他人，尤其是您的最终用户、务实的开发人员以及为硬件和软件开发付费的人，他们可能会说性能受到较大影响会更糟。

DDD 和许多其他设计方法一样值得称赞，但是如果您教条地遵循它们以提出“纯”设计，那么它们所有都会失败现实世界的考虑因素，例如性能。

如果您真的必须对数据执行此类查询，那么几乎可以肯定数据库远能够更好地执行该任务。

或者，您是否在这里“错过了一个把戏”。你的设计，无论多么 DDD，实际上是不对的吗？

总体而言 - 适本地使用您的工具。一定要努力在您的服务层中保持逻辑清晰分离，但不要在该逻辑执行大量数据库设计的工作时。