如何在不继承 TableEntity 或实现 ITableEntity 的情况下创建自定义实体

Question

是否可以在不实现 ITableEntity 或从 TableEntity 继承的情况下创建自定义实体？

如果我正在实施 ITableEntity，那么它会迫使我实施一些我不想实施的其他方法。

如果我从 TableEntity 继承我的自定义实体，那么我需要在将它传递给表操作之前对其进行更新，这会引入无法模拟的直接依赖关系，并且我的控制器类变得不可测试。

我想要做的就是创建我的自定义实体并保存在 Azure 表存储中。

Answer 1

\n

是否可以在不实现 ITableEntity 或继承 TableEntity 的情况下创建自定义实体？

\n

\n\n

斩钉截铁地说：没有。
\n您需要实现此接口或继承此类的原因是TableOperation作为ITableEntity参数。

\n\n

如果你确实希望只能使用自己的类和接口，那么你可以自己实现与Azure服务的通信。例如，这里是插入实体操作的描述。您必须编写一个包装器来...复制 Microsoft 库提供的现有功能。

\n\n

但看起来你正在尝试做一些奇怪的事情。
\n第一个奇怪的事情是您正在尝试测试控制器。通常你不会这样做。您能使用什么类型的控制器以及为什么要测试它们？
\n第二个奇怪的事情是，您试图将从 TableEntity 继承或实现 ITableEntity 的某些方法传递给某个不是存储库的方法或某个仅在数据层中工作的类。

\n\n

通常，您永远不会在数据层类之外使用实现 ITableEntity 或从 TableStorage 继承的东西。该类应该只从某些存储中读取并检索映射到业务对象数据或写入某些存储，将DTO 或业务层对象本身或简单类型（如 string、int、DateTime）作为参数的. 而且这样的类是不可测试的。它是数据层，您应该测试业务逻辑或处理原始数据和数据存储的业务逻辑之上的某些层。

\n\n

因此，请考虑在您的系统 \xe2\x80\x94 存储库或某种类似的存储库中引入新的抽象级别，它将与存储一起工作，返回业务对象。这种抽象应该有一个可以轻松模拟和测试的接口。此类的方法应采用业务层对象、DTO 或 .NET 类型的对象。它仅用于 DI，不用于测试。此类类通常不经过测试。

\n