Arthur,
This is not an acceptable answer. For enterprise class systems, ASPNet WebApi is a joke. I really don't want to expose my CRUD out of a service and have all of my business logic in the client.
Consider the following scenario: I have a WPF application that communicates with WCF services to do work. Models are serialized back to the WPF client and the WPF client calls service operations on the server, some of which are forwarded to another server (like a BI server) to perform the work. The "recommended" solutions simply don't support this well.
I need objects to be trackable when they're completely detached from the DbContext, and this is something that EF should provide. Shoot, just give me a ClientObjectChangeTracker or something similar and I'll attach to that context for change tracking, it doesn't have to be built into the poco's themselves.
Tony, I've looked at your solution, and I'm not convinced.
In short, killing STE's sucks big time.
Robert
This is not an acceptable answer. For enterprise class systems, ASPNet WebApi is a joke. I really don't want to expose my CRUD out of a service and have all of my business logic in the client.
Consider the following scenario: I have a WPF application that communicates with WCF services to do work. Models are serialized back to the WPF client and the WPF client calls service operations on the server, some of which are forwarded to another server (like a BI server) to perform the work. The "recommended" solutions simply don't support this well.
I need objects to be trackable when they're completely detached from the DbContext, and this is something that EF should provide. Shoot, just give me a ClientObjectChangeTracker or something similar and I'll attach to that context for change tracking, it doesn't have to be built into the poco's themselves.
Tony, I've looked at your solution, and I'm not convinced.
In short, killing STE's sucks big time.
Robert