实体框架：POCO和IQueryable代码的封装

发布于 2024-11-08 17:18:34 字数 156 浏览 0 评论 0原文

问题是关于方便的代码组织。

我已将 POCO 类移至持久性独立项目。我应该将 IQueryable 代码（这些 POCO 周围的“业务规则”的一部分，例如用于生成派生的非持久业务对象）一起移动，还是最好将所有 IQueryable 代码留在具有 ObjectContext 的库中？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

甜妞爱困 2024-11-15 17:18:34

在您的评论中，您说，“这意味着持久性独立库可以包含 IQueryable 表达式，这些表达式在没有持久层的情况下“不可执行/可测试”......”。那不是真的。您可以以（大部分）与持久性无关的方式测试 IQueryable 表达式。

例如：

public IQueryable<Foo> SomeFoos(IQueryable<Foo> foos, string aValue)
{
    return from foo in foos 
           where foo.Bar = aValue
           select foo;
}

您可以将其与 L2E 一起使用：

var f = SomeFoos(myContext, "Baz");

您可以使用 L2O 对其进行测试：

var expected = new Foo { Bar = "Baz" };
var notExpected = new Foo { Bar = "Oops" };
var input = new [] { expected, notExpected };

var actual = instance.SomeFoos(input.AsQueryable(), "Baz");

Assert.AreEqual(actual.First(), expected, "Should have found expected record.");
Assert.AreNotEqual(actual.Single(), notExpected, "Should not have found unexpected record.");

这是一个虚构的示例，但希望要点很清楚：如何构建它实际上取决于您，正如 @Ladislav 所说。

In your comment, you say, "That means that persistence independent library can contain IQueryable expressions which are "not executable/testable" without persistence layer...". That's not true. You can test IQueryable expressions in a (mostly) persistence-independent manner.

E.g.:

public IQueryable<Foo> SomeFoos(IQueryable<Foo> foos, string aValue)
{
    return from foo in foos 
           where foo.Bar = aValue
           select foo;
}

You can use this with L2E:

var f = SomeFoos(myContext, "Baz");

You can test it with L2O:

var expected = new Foo { Bar = "Baz" };
var notExpected = new Foo { Bar = "Oops" };
var input = new [] { expected, notExpected };

var actual = instance.SomeFoos(input.AsQueryable(), "Baz");

Assert.AreEqual(actual.First(), expected, "Should have found expected record.");
Assert.AreNotEqual(actual.Single(), notExpected, "Should not have found unexpected record.");

This is a made-up example, but hopefully the point is clear: How you structure this really is up to you, as @Ladislav states.

回复收藏 0 原文

~没有更多了~