As I understand, Proxied POCO objects can track changes only being attached to ObjectContext. On the contrary STE track开发者_StackOverflows changes even being detached. I am curious why there is no support for a POCO proxy which will implement STE behaviour internally?
Take this only as my personal opinion.
There are no "self tracking proxies" because for current implementation it would nor make sense. Why:
- Self tracking entities were developed to support change set scenarios over web services where entity is able to track changes on the client side, client will pass these changes back to service and entity will apply changes back to a new instance of the context.
- To make this work client and service must share implementation of self tracking entities.
That is supposed usage of STEs. In any other scenario they don't have too much sense
- In WinForms / WPF / Service application directly accessing EF you don't need them and it is generally a bad scenario to use them because you can use attached entities directly.
- In Web application you don't want them because it would require storing them either serialized in page (= same as view state) or in session / cache. First scenario is design approach which is dead for many years and you should simply not use it and second should be avoided as much as possible.
So where do you see the usage of "self tracking proxies"? Do you want to use them instead of STEs? Why? And more importantly how? Main advantage of STEs implementation is that they are serializable whereas dynamically created proxies are not! If you check how serialization over web services (WCF) work you will see that all serializable types passed through services must be know when the service is started. Otherwise only basic unproxied will be exposed.
精彩评论