1

如果使用带有实体框架的 STE，在构建将通过 wcf 接收实体的客户端应用程序（例如网站）时，是否需要引用模型 dll 程序集（其中包含类的定义？）以实现所有功能STE的？

或者，当您只使用从服务 wsdls' 生成的代理类时，您会失去哪些功能？

4

2 回答 2

2

不确定 100%，但 STE 旨在在反序列化后开始跟踪。如果您最终使用生成的代理类，您将丢失客户端的所有跟踪代码。我不相信生成的实体可以跟踪实体在服务器端从客户端代理重新水化时发生的变化，所以我肯定会引用模型程序集。

于 2011-01-07T13:59:56.540 回答
0

STE 设计为在反序列化后开始跟踪，自跟踪功能通常可用于确定发生了什么变化，以便您只传递必要的线路更改。

自跟踪实体是实体框架 v4 中引入的一种时尚的 EF 实现。它被 EF6 中的 DbContext（服务器）和 ODataClient（客户端）取代，其中跟踪上下文与实体本身分离。

STE 模型通常在模型类中混合一组丰富的业务逻辑，这些模型类是为 RPC 样式耦合而设计的，其中 dll 预计将在客户端使用，而不是生成的代理类。

如果您使用客户端上的 WSDL 或 $metadata生成的代理类，则模型中的任何自定义业务逻辑都不存在于客户端上。此业务逻辑将采用属性设置器或更改处理程序中的代码形式，用于验证、拒绝或对更改做出反应。将这种复杂逻辑传递到客户端的唯一方法是将 dll 分发给客户端开发人员，否则您必须依靠他们在需要时复制它的能力。

STE 提供了一种远程代码解决方案，该解决方案提供了一种机制，用于发布将在客户端执行的服务器定义的业务逻辑，其目的是验证业务规则并减少通过网络发送的字节数。

您仍然可以在客户端生成简单的 CRUD 更改跟踪，但如果您最终使用生成的代理类，则服务器定义将被完全忽略，您将丢失可能在服务器上定义的任何丰富的跟踪和验证代码。

当使用客户端生成的代理时，服务器无法做出任何假设。因为在 API 项目中客户端总是可以选择不使用您的 dll 并生成自己的代理，因此重新验证、清理和验证来自客户端的所有输入非常重要。

通过网络发送更改历史记录是不切实际的，大多数 STE 实现使用跟踪来确定要发送什么信息，但是服务器没有收到更改堆栈，而是期望服务器逻辑要么假设整个有效负载表示应该存储的完整状态（通过将实体附加到服务器上下文），或者它需要通过与存储在服务器上的当前值进行比较来生成它自己的更改图。

如果 STE 作者认为有必要，他们将提供客户端模型，一般来说，如果提供 DLL，如果您使用它们应该可以节省大量时间和管理。

STE 已经过时，主要是由于 API 开发人员在提供合规 DLL 方面的维护负担，但也由于通常只需要 API 子集的客户采用率低，因此更有可能接受解决方案与服务器的物理实现和结构分离。EF 和 OData 已经发展到解决 STE 框架旨在解决的原始问题。

于 2021-07-15T11:05:57.827 回答