如果将 STE 与实体框架一起使用，则在构建将通过 wcf 接收实体的客户端应用程序（例如网站）时，是否有必要引用模型 dll 程序集（其中包含类的定义？）以实现所有功能STE的？
或者，当您只使用从服务 wsdls 生成的代理类时，您会丢失哪些功能？
If using STE's with entity framework, when building the client application (say web site) which will receive the entities via wcf, is it necessary to reference the model dll assembly (which contains the definitions of the classes?) to achieve all the features of STE's?
Alternatively, when you just use the proxy classes that are generated from the service wsdls', what features do you lose?
发布评论
评论（2）
不确定 100%，但 STE 设计为在反序列化后开始跟踪。如果您最终使用生成的代理类，您将丢失客户端的所有跟踪代码。我不相信生成的实体可以跟踪实体在服务器端从客户端代理重新水合时发生的更改，因此我肯定会引用模型程序集。
Not sure 100%, but STEs are designed to start tracking after deserialization. If you end up using generated proxy classes, you're going to lose all that tracking code on the client side. I do not believe the generated entities can track changes that happen at the time the entities are rehydrated on the server side from client proxies, so I'd definitely reference the model assembly.
STE 设计为在反序列化后开始跟踪，自跟踪功能通常可用于确定已更改的内容，以便您仅传递线路的必要更改。
STE 模型通常在模型类中混合了一组丰富的业务逻辑，这些模型类是为 RPC 样式耦合而设计的，其中 dll 预计在客户端使用，而不是生成的代理类。
如果您使用客户端上的 WSDL 或 $metadata 生成的代理类，则客户端上不存在模型中的任何自定义业务逻辑。该业务逻辑将采用属性设置器或更改处理程序内的代码形式，用于验证、拒绝更改或对更改做出反应。将这种复杂逻辑传递给客户端的唯一方法是将 dll 分发给客户端开发人员，否则您必须依赖他们在需要时复制它的能力。
您仍然可以在客户端上生成简单的 CRUD 更改跟踪，但如果您最终使用生成的代理类，则服务器定义将被完全忽略，您将丢失可能在服务器上定义的任何丰富的跟踪和验证代码。
通过线路发送更改历史记录是不切实际的，大多数 STE 实现使用跟踪来确定要发送哪些信息，但服务器不会接收更改堆栈，相反，预计服务器逻辑将承担整个有效负载表示应存储的完整状态（通过将实体附加到服务器上下文），否则需要通过与服务器上存储的当前值进行比较来生成自己的更改图。
如果 STE 作者认为有必要，他们会提供客户端模型，一般来说，如果提供了 DLL，那么如果您使用它们，应该可以节省大量时间和管理。
STEs are designed to start tracking after deserialization, the self tracking functionality is generally useful for determining what has changed so that you only pass the necessary changes of the wire.
STE models generally mix a rich set of business logic inside the model classes that are designed for RPC style coupling where the dlls are expected to be used on the client side instead of generated proxy classes.
If you use generated proxy classes from the WSDL or $metadata on the client, any custom business logic within the model does not exist on the client. This business logic would be in the form of code inside property setters or change handlers that either validates, rejects or reacts to changes. The only way to get this complex logic onto the clients is to distribute the dlls to client-side developers, otherwise you must rely on their ability to replicate it when needed.
You can still generate simple CRUD change tracking on the client but if you end up using generated proxy classes, the server definition is totally ignored, you lose any rich tracking and validation code that might be defined on the server.
It is not practical to send the change history across the wire, most STE implementations use the tracking to determine what information to send, but the server does not receive the change stack, instead it is expected that the server logic would either assume the entire payload represents the complete state that should be stored (by attaching the entity to the server context) or it will need to generate it's own change graph by comparing to the current value stored on the server.
STE authors will make the client models available if they think it is necessary, in general if the DLLs are provided it should save a lot of time and management if you use them.