I'd like to know if CSLA would be a good fit for a project that I'm preparing to work on based the folllowing scenario encountered in the project: I will have a .NET application that will need to allow for multiple instances to be open simultaneously (on a given desktop machine). There will also be one separate "app" that will act as a gateway to the multiple instances. Specifically, this separate "app" will contain an ActiveX control that receives messages from telephony software and needs to pass call information to one of the open instances (or open a new instance, if required). (Note that this messaging "app" is really part of the same overall application...it will not be utilized by anything other than these opened instances of the main MDI form.)
In other words:
I was beginning to read up on WCF to allow communication across app domains, but from my prior reading on CSLA I think I remember that this handles these types of things. Does this scenario sound like something for which CSLA would be a good framework? Thanks.
CSLA doesn't address this type of messaging requirement, no. CSLA uses WCF to handle messaging (or other similar technologies).
CSLA may help with other aspects of the app (assuming you have a UI, its support for data binding is always useful), but it won't help the messaging.
Thanks for the response. So whether I utilize CSLA or not, would your recommendation be to look into WCF to handle this kind of messaging? Or is there something else that I should be looking to? BTW - the app does have a UI.
There are probably several options, but using WCF with a named pipe channel is probably the most direct route. MSMQ is something I've also used in the past, but that requires MSMQ be installed on the machine (which it isn't by default for client OSes like Win7).
Good question - I would like to do that and get away from this model (currently existing in a VB6 form - we're slowly starting to migrate small pieces to .NET using the Interop Forms Toolkit). The initial VB3(?) design of this app was done is such a way that the users launch separate instances of the MDI parent whenever they need to. Its an order entry application, and instead of having one parent form within which multiple child order entry forms could be launched, a new MDI parent form is launched each time they need to service a different customer. They might take a call from one customer, start taking down order info and then get a call from another customer. They'll minimize the first MDI parent (instance A) and launch another one (instance B) to work on so their first instance doesn't loose its state. Basically, the "messaging" app is where the call information comes in to, and it will give them the option to select/use one of their already-opened MDI parent instances if they want, or launch a new instance if they so choose. I'd love to hear other ideas about how to deal with this (other than re-writing the entire app from scratch the right way...I'd like to do that but it is a massive application and we simply can't do that right now).
The other aspect to this is that the ActiveX control that handles incoming call information shares state with all opened applications that utilize the control. So if all MDI instances have the ActiveX control on them, an event really intended for one of those instances gets raised on all of the instances. We have some work-arounds, but having one instance like a server/messaging app might (or not) minimize the complexity...that's what I'm trying to decide - does having to deal with WCF increase the complexity in one way while minimizing it another way. Thoughts are welcome.
Take a look at a messaging framework. I've used NServiceBus in similar scenario and it worked great.
NServiceBus uses MSMQ.
There is also MassTransit
http://code.google.com/p/masstransit/
HTH..
Copyright (c) Marimer LLC