1

我读了这篇关于模拟 Entity Framework(EF) 的帖子。

我们不应该也抽象实体的类型吗？为了保持数据访问层 (DAL) 和业务层 (BL) 之间的解耦？

在上面的帖子中，他使用了 EF 具体生成的实体类型：

[TestMethod]
public void GetCustomer()
{
    ContextContainerMock container = new ContextContainerMock();
    IMyEntities en = container.Current;

**Customer c = new Customer { ID = 1, FirstName = "John", LastName = "Doe" };**
    en.Customers.AddObject(c);

    CustomerService service = new CustomerService(container);
    var a = service.GetCustomer(1);

    Assert.AreEqual(c.FirstName, a.FirstName);
    Assert.AreEqual(c.LastName, a.LastName);
}
4

2 回答 2

2

就个人而言，我不嘲笑这些。我直接创建、测试和清理。这帮助我在处理数据库时发现了更真实世界场景的问题。模拟非常适合测试您可能无法访问数据库等资源的集成。如果这是你的情况，那么你可能别无选择。希望有帮助。

于 2012-10-28T13:42:52.020 回答
0

最简洁的答案是不。

如果正确完成，实体不依赖于任何其他代码，除了其他实体和值对象（例如字符串、int 或您自己的值对象）。因此，没有必要嘲笑它们。

此外，实体是系统核心的一部分。它们就是您的系统的全部内容。您通常希望测试系统在对这些类进行操作时的行为，而不是测试系统在对测试所描述的行为进行操作时的行为。

（作为旁注，您的实体应该看起来和行为类似于现实世界中存在的东西。也就是说，您应该能够从组织的业务方面与非技术人员推理行为。从你的例子我看到可以创建一个没有名字的客户。从业务角度来看可以吗？如果不是，我会说你应该让构造函数将名字和姓氏作为参数。）

于 2012-10-29T20:01:06.483 回答