Valeriu, This should also be possible. I created a working prototype of that approach roughly 6 months ago. I should still have it somewhere on my disc, I also sent it to Craig. Actually, there's nothing stopping us from having both. If a used does it that (explicit) way, proxy won't implement IAsyncCall If he doesn't he may stil be able to use implicit version. I don't like this approach very much, because you still have to manually create second type, that adds no value to your code, and you have to remember how to name methods, what attribtutes you must copy, what attributes you must not etc. Then you must make sure to keep them both in sync etc... Doing all of that simply to satisfy a tool is WRONG in my personal opinion. That's why I'm trying to do it the DRY way, but sure - there's nothing stopping us from having both if that's what you prefer. And you still have to cast to interfaces if you use the proxy, for example ICommunicationObject comes to mind when you want to be notified or its state machine transitions. We could use explicit external static class that would do that for us... However I don't really like static classes since they complicate the picture when you want to test something. Last but not least, thanks for the input :) Krzysztof
>>> [email protected] 2009-05-07 10:14 >>> Well, we make use of WCF Facility in our projects except for calling async services. But comparing the syntax you have and writing the async version of service contract, I'll choose the second, event if it's not DRY friendly. It's more "discoverable". I take IMyServiceAsync & just calling it. Your way I should remember to cast IMyService to something, setting some props (even fluently). This is my personal preference. May be when I'll see the whole picture, I'll change my mind... The way I would like it is: interface IMyServiceAsync : IMyService {} Component .For<IMyServiceAsync>() .IsAsyncOf<IMyService>() .ActAs(..... This will remove the hassle to mentain two versions of service contracts. Doing some code generation or AOP should make it possible. Still not sure if effort will be justifiable. Valeriu On May 6, 9:47 pm, Krzysztof Ko*mic <[email protected]> wrote: > I'm working on adding to WCF Facility support for async calls from > client side (similar to what can be done with SvcUtil-generated > proxies), when using channelfactory and intereface contract only. > Something like What Ayende wrote about here:http://ayende.com/Blog/archive/2008/03/29/WCF-Async-without-proxies.aspx > but without having to write IAsyncBus > > I have very rough (but working) implementation. > > But... > > given we don't have an actual async methods to call, we have to have an > alternative syntax (well, at least until C# 4.0 and IDynamicObject, but > that's another story)http://paste2.org/p/198506here's what I came up with. > I encourage you to discussion about it. If you have alternative, better > ideas, you can show it here:http://paste2.org/followup/198506 > > Thanks, > > Krzysztof CONFIDENTIALITY NOTICE This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged, confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please delete all copies of this message and notify the sender immediately by return mail or fax ATSI S.A.(+4812) 285 36 04. Any email attachment may contain software viruses which could damage your own computer system. Whilst reasonable precaution has been taken to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening any attachments. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
