如果将STE与实体框架一起使用，在构建将通过wcf接收实体的客户端应用程序（比如网站）时，是否有必要引用模型dll程序集（其中包含类的定义？）来实现所有STE的特点？
或者，当您只使用从服务wsdls'生成的代理类时，您会丢失哪些功能？
答案 0 :(得分：1)
不确定100％，但STE设计为在反序列化后开始跟踪。如果您最终使用生成的代理类，那么您将丢失客户端上的所有跟踪代码。我不相信生成的实体可以跟踪实体在服务器端从客户端代理重新水化时发生的更改，因此我肯定会引用模型程序集。
答案 1 :(得分：0)
STE 被设计为在反序列化后开始跟踪，自我跟踪功能通常用于确定发生了什么变化，以便您只传递线路的必要变化。
<块引用>Self Tracking Entities 是实体框架 v4 中引入的一种流行的 EF 实现。它被 EF6 中的 DbContext（服务器）和 ODataClient（客户端）取代，其中跟踪上下文与实体本身分离。
STE 模型通常在模型类中混合了一组丰富的业务逻辑，这些模型类专为 RPC 样式耦合而设计，其中 dll 应在客户端使用，而不是生成的代理类。
如果您在客户端上使用 生成的代理 WSDL 或 $metadata 类，则该模型中的任何自定义业务逻辑在客户端上都不存在。此业务逻辑将采用属性设置器或更改处理程序中的代码形式，用于验证、拒绝或响应更改。将这种复杂逻辑传递到客户端的唯一方法是将 dll 分发给客户端开发人员，否则您必须依赖他们在需要时复制它的能力。
<块引用>STEs 提供了一个远程代码解决方案，该解决方案提供了一种机制，用于发布将在客户端执行的服务器定义的业务逻辑，其明确意图是验证业务规则并减少跨网络发送的字节数。电线。
您仍然可以在客户端生成简单的 CRUD 更改跟踪，但如果您最终使用生成的代理类，则服务器定义将被完全忽略，您将丢失可能在服务器上定义的任何丰富的跟踪和验证代码。
<块引用>当使用客户端生成的代理时，服务器无法做出任何假设。因为在 API 项目中总是可能让客户端选择不使用您的 dll 并生成他们自己的代理，所以重新验证、清理和验证来自客户端的所有输入很重要.
通过线路发送更改历史记录是不切实际的，大多数 STE 实现使用跟踪来确定要发送的信息，但服务器不接收更改堆栈，而是期望服务器逻辑要么假设整个有效负载表示应该存储的完整状态（通过将实体附加到服务器上下文）或者它需要通过与服务器上存储的当前值进行比较来生成它自己的变化图。
如果 STE 作者认为有必要，他们会提供客户端模型，一般来说，如果提供了 DLL，使用它们应该可以节省大量时间和管理。
<块引用>STE 已经过时，这主要是因为 API 开发人员承担了提供兼容 DLL 的维护负担，而且还因为客户的采用率较低，他们通常只需要 API 的一个子集，因此更有可能接受与服务器的物理实现和结构分离的解决方案。 EF 和 OData 已经发展到可以解决 STE 框架旨在解决的原始问题。