If this will be a one-off and one or two classes, I don't want to send you
off on into a mess. But if you will be doing a lot of this in your app, it
is a pattern that can bear a lot of fruit and simplify things. For some
background, check out
http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf
It is server focused, but the same idea is great for client side and UI
update processing as well. Some nice things are: message based, not method
based so it is easy to refactor code and is loosely coupled. It is
naturally pluggable for easy adding and changing Stages, even at runtime.
Each stage can send messages back to itself or any other stage. Shutdown
processing is as easy as sending a stop message which gets sent along your
Stages (this can sometimes be one of the harder issues to handle cleanly
with other patterns). You can throttle and manage speed at each stage as
you have the queue as the focus point. Many others. First, you will need a
bounded-blocking thread safe queue. Here is mine that also have some
examples using pipes and queues and thread pools.
http://channel9.msdn.com/ShowPost.aspx?PostID=161030 I am actually working
on a server using this "SEDA" pattern and seems to make a lot of sense so
far and seems to be clean. I will try to work up something simple and put
in the C9 Sandbox.
--
William Stacey [MVP]
"Bob Jones" <dd******@eskyesolutions.com> wrote in message
news:uL****************@TK2MSFTNGP15.phx.gbl...
| William,
|
| Thank you for that. It's a shame I have no idea how to implement what you
| are speaking of. Can you point me (and others reading this) in the right
| direction?
|
| Regards..
|
|
| "William Stacey [MVP]" <wi************@gmail.com> wrote in message
| news:Od****************@TK2MSFTNGP15.phx.gbl...
| > Sounds like a pipeline. Instead of using delegates and events, I would
| > use
| > message passing. Each class will expose a bounded queue (blocking
style)
| > and have a worker thread (or a user TP) block on messages and handle
them
| > as
| > needed.
| >
| > --
| > William Stacey [MVP]
| >
| > <go********@gmail.com> wrote in message
| > news:11**********************@f14g2000cwb.googlegr oups.com...
| > | Hey everyone, I need some advice concerning Interfaces and delegates.
| > |
| > | I would like to define a delegate inside of an interface (I know a
| > | delegate is a class but hear me out)
| > |
| > |
| > | Here is a sample:
| > |
| > | Interface A
| > |
| > | Class B inherits Interface A
| > |
| > | Program C creates an instance of Class B and needs to consume events
| > | from Class B.
| > |
| > | I would like for Class B to be required to implement the delegates via
| > | Interface A. Is this possible? Is this proper? Can/Should I use an
| > | abstract class for this? Is there a better way?
| > |
| >
| >
|
|