Hiya
In a word... yes. This is one of the benefits of interface based programming that Spring.NET facilitates. Your code and configuration as described in your post will work (from what I can see).
Let’s says you have an assembly called MessageProcs that contains interfaces only. One of the interfaces it contains is called (as per your example) IProcessMessage (I have taken some liberties with your interface since you don’t describe it in depth)...
using System;
using System.Collections;
namespace MessageProcs {
public interface IProcessMessage
{
void ProcessMessage(object message, IDictionary properties);
}
}
You have another, separate assembly called SampleBusinessObj (as per your example). It contains a class (SampleBusinessObj, in the SampleBusinessObj namespace) that implements the IProcessMessage interface. This assembly needs (of course) to reference the MessageProcs assembly.
using System;
using System.Collections;
using MessageProcs;
namespace SampleBusinessObj
{
public class SampleBusinessObj : IProcessMessage
{
public void ProcessMessage(object message, IDictionary properties)
{
Console.WriteLine(message);
}
}
}
You have another, separate assembly called MessageController (as per your example). It contains one or more classes that use the IProcessMessage interface. It doesn't care (or need to know) what the implementation of the IProcessMessage interface is, it simply needs the interface; so it too needs (of course) to reference the MessageProcs assembly (but not the SampleBusinessObj assembly). Find below a very simple example...
using System;
using System.Collections;
using System.Configuration;
using MessageProcs;
using Spring.Context;
namespace MessageController
{
public class SimpleMessageController
{
public void SendMessage(object message)
{
IApplicationContext ctx = ConfigurationSettings.GetConfig("spring/context") as IApplicationContext;
IProcessMessage myBusObj = (IProcessMessage) ctx["TestBusinessObj"];
myBusObj.ProcessMessage(message, new Hashtable());
}
}
}
So what you want to do is wire up the SampleBusinessObj class (which is a concrete implementation of the IProcessMessage interface), to the SimpleMessageController. As per your code (more on this later), the SimpleMessageController gets a reference to an IApplicationContext and pulls 'some' IProcessMessage implementation instance out of the context. It doesn’t know exactly what implementation, and it doesn’t care. The exact implementation is configured in the context configuration file...
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="spring">
<section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core" />
<section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</sectionGroup>
</configSections>
<spring>
<context>
<resource uri="config://spring/objects" />
</context>
<objects xmlns="http://www.springframework.net">
<description>A client example that demonstrates a local call.</description>
<object name="TestBusinessObj"
type="SampleBusinessObj.SampleBusinessObj, SampleBusinessObj"/>
</objects>
</spring>
</configuration>
This works... the SampleBusinessObj assembly is not referenced by either the MessageProcs assembly or the MessageController assembly. This is what you wanted to know right? The SampleBusinessObj assembly can simply be 'dropped' into the same directory as the application (if you are doing a rich client), or it can be dropped into the 'bin' directory of your web apps virtual directory if you are doing an ASP.NET application; it can also be strongly named and installed into the GAC too (you will have to sign the MessageProcs assembly too in this case)... Spring.NET will locate your assembly and plug it in 'dynamically for you. There's no magic here, just plain old .NET assembly resolution going on under the covers.
Finally :) ... the example code I have described here is not the best way to get the most bang for your buck out of Spring.NET (and IoC in general); I simply tried to best answer the question at hand. The SimpleMessageController class would be better off being configured in the context itself (maybe you can't do this, I don’t know), so that it can have its dependency on an IProcessMessage instance supplied by the container. To wit...
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="spring">
<section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core" />
<section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</sectionGroup>
</configSections>
<spring>
<context>
<resource uri="config://spring/objects" />
</context>
<objects xmlns="http://www.springframework.net">
<description>A client example that demonstrates a local call.</description>
<object name="TestBusinessObj"
type="SampleBusinessObj.SampleBusinessObj, SampleBusinessObj"/>
<object name="MessageController"
type="MessageController.SimpleMessageController, MessageController">
<property name="MessageProcessor">
<ref object="TestBusinessObj"/>
</property>
</object>
</objects>
</spring>
</configuration>
With the SimpleMessageController class being changed like so; yeah you have to make a change to your code, but its for the better (your mileage may vary - I daresay you know your specific business requirements a whole lot better than me, so I'll leave it with you), 'cos your SimpleMessageController class is now much easier to test, and doesn't have a whole lot of Spring.NET specific dependencies and lookup code in it anymore.
using System;
using System.Collections;
using System.Configuration;
using MessageProcs;
using Spring.Context;
namespace MessageController
{
private IProcessMessage _messageProcessor;
public class SimpleMessageController
{
public void SendMessage(object message)
{
_messageProcessor.ProcessMessage(message, new Hashtable());
}
public void MessageProcessor
{
set
{
_messageProcessor = value;
}
}
}
}
Of course, you might want to have the SimpleMessageController class implement an interface, so that it too can be wired in to your other classes with a minimum of dependencies :)
Hope this answers your question... if not, just bang away on that 'Post Reply' button.
Have a kicking the-rest-of-your-weekend, ciao
Rick