Krzysztof, when I gave this example:
interface IMyServiceAsync : IMyService {}
Component
.For<IMyServiceAsync>()
.IsAsyncOf<IMyService>()
.ActAs(.....
...I'm not about maintaining two versions manually. I meant that you should
declare only the (empty) async interface. The rest - generation of
Begin...()/End...() & sync-ing atributes on operation contracts should be
done for example in a post-build step, by a code generation tool. But, as I
said previously, still not sure if I'd like this solution.
Looking forward to see your implementation & other's ideas...
Valeriu
On Thu, May 7, 2009 at 10:29 AM, Krzysztof Kozmic <[email protected]>wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
