New Posts New Posts RSS Feed: Event such as Querying/Fetching/Saving for InvokeServerMethod calls
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Event such as Querying/Fetching/Saving for InvokeServerMethod calls
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166 		Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post Topic: Event such as Querying/Fetching/Saving for InvokeServerMethod calls
    Posted: 20-Feb-2013 at 4:10pm
The EntityManager class has events such as Querying/Queried, Saving/Saved, Fetching, etc. but none of those fire if you do an InvokeServerMethod (or InvokeServerMethodAsyc) call.  There is some standard logging and other cross-cutting logic that we currently perform in Quering/Queired that we'd really love to be able to do for InvokeServerMethod calls as well.

I made a similar request for the server side of this issue in "Interceptors for RPC methods?" that didn't get too far.  In that case, it's not too hard (although still annoying) to make sure I add some boilerplate code in every RPC method.  But on the client side, it's much harder to remember to put boilerplate code whenever I invoke a server method.  Plus, making the caller do it makes the code much less readable and harder to maintain.

I'm sure this won't be a super high priority, but I think it would be a somewhat simple change to make and it would really help us out.

Thanks!
Back to Top
mgood View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583 		Post Options Post Options   Quote mgood Quote  Post ReplyReply Direct Link To This Post Posted: 20-Feb-2013 at 5:23pm
In the meantime you could create yourself an InvokeServerMethodWithBoilerplateAsync extension method and ensure everybody uses that extension method instead of the raw method on the EntityManager. Gets your boilerplate code out of the way and in one place. Should be very easy to catch during a code review if a developer is bypassing the extension method.
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391 		Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 22-Feb-2013 at 10:06am
Stephen, we haven't completely forgotten your request for RPC interceptors - it's still an open feature request, albeit not very high priority.  We'll add another feature request for a client-side event (or events - do you have a use case for both pre- and post- events?), but please also see if Marcel's suggestion will work for you. 
Back to Top
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166 		Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post Posted: 22-Feb-2013 at 12:18pm
Thanks for the update.

Pre- and Post- events would both be helpful.  In some cases, we do timing logic so we need to know when a query started and when it finished.  Post events are also nice because we have access to the results of the operations.  Pre events are nice because we have some hooks to the original operation in case we need to do any tweaking there.

We use InvokeServerMethods in so many places that I ended up giving up on trying to make extension methods and then update all existing usages.  I know it's possible, but it just leaves the chance of human error.  I did find a bit of a workaround by intercepting all WCF calls - this gives me a chance to inspect the calls, dig around and find information about what DevForce is executing.  This gives me the hooks I need to have a pre-event - although, it's not the cleanest solution.

For now, I'll just wait patiently.  It's not the end of the world for us.....but it would still be nice! :-)
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down