> From: Daniel Krieg [mailto:[EMAIL PROTECTED]] > > Berin, > > Thanks for your reply. I have some followup questions that you > may be able to address. The application I am developing will > be a server app hosted within Phoenix. Several of the sub-system > components that I am developing are an assembly/composition of > smaller services/components. These sub-system components are > unlikely to change configuration often, however with respect > to Phoenix, > the assembly of these Blocks (sub-system components) will likely > change...(Does this make any sense???)
I think so. > I think it is more appropriate to implement these sub-system > components using Fortress Container and assemble them together > as Phoenix Blocks. One requirement I have is that these components > take advantage of the SEDA architecture within Excalibur Events. > I would like to use CommandManager to handle dispatching of > Commands. Does the DefaultContainer do this implicitly? What > alternatives are available? The DefaultContainer has a reference to the CommandManager's Sink. It passes a reference to that Sink via the Context at this time. The key is in the ContainerConstants interface AFAIR. > Is it more appropriate to define my sub-system components by > extension or containment of the Fortress DefaultContainer? It depends on what you want to do. If you are merely *using* the Fortress DefaultContainer, then contain it. If you want to change some aspects of how it configures information, then extend it. In most cases, I suggest containment. > If I have a component A and component B needs to send a > Command to component A, and that Command needs access to > a service held within component A in order to execute, what is > the proper IOC approach? (...Again, make any sense???). Let's see if I can refrase this: Component B wants to perform an asynchronous operation on Component A. In order to make this happen, the Command needs a reference to the other component. There are two ways you can achieve that: 1) Pass in the ServiceManager to the Command, and let the Command lookup Component A. 2) Pass in a reference to Component A. The tradeoffs are: Option 1 allows you to work with components of any lifestyle, making the lookup/release cycle all within one context. Option 2 forces you to work with "ThreadSafe" components, or provide complicated and error prone lookup/release logic. Either approach will allow you to perform whatever you need to do. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
