Valeriu,
Now I'm confused.
by "(empty) async interface"
you mean nothing more than:
public interface IMyServiceAsync{}
is that right?
Then what does it buy you? You still don't have async methods at
compile time... so you won't get to the postcompile step, because you
won't pass the compile step.
And if you want to codegen at implementation time, this brings its own
set of drawbacks.
Also code generation is outside of the scope ot Castle so with regards
to my previous post, the way you maintain the async interface, whether
its by codegen or manual implementation is just an implementation
detail. The fact still stands that you are responsible for doing this -
not the framework.
Krzysztof,
>>> [email protected] 2009-05-07 11:00 >>>
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.
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
-~----------~----~----~----~------~----~------~--~---