Some background

As a cohesive framework, NServiceBus makes it quite easy for developers to pick and choose which settings they want turned on and off. Being built as a loosely-coupled set of components that don’t know about each other has always kept the internal complexity low. But as the NServiceBus API has been evolving over the years, and the functionality offered has increased, some interesting challenges have popped up as the codebase has been refactored.

The challenge

The UnicastBus class has grown too large and it’s time to refactor something out. Coincidentally, users have been asking for a better “header” story for messages – the ability to specify static headers that will be appended to all messages being sent (useful for things like security tokens), as well as per message headers. So, we want to refactor all the header management out to its own component independent of the UnicastBus class.

So, here’s the issue. So far, users have specified “.UnicastBus()” as a part of the fluent code-configuration, and shouldn’t have to change that – they shouldn’t need to know that header management is now a separate component. But then how can the new component bootstrap itself into the startup, such that it gets all the dependency injection facilities of the rest of the framework? Remember that the component doesn’t know which container technology is being used (since the user can swap it out) or when the container has been set.

The solution

The only part of the framework that knows about when all DI configuration is set is the configuration component, thus it will have to be the one that invokes the new component (without knowing about it). Introduce an interface (say INeedInitialization) and scan all the types loaded looking for classes which implement that type, register them into the container, and invoke them. Have the new component implement that interface, and in its initialization have it hook into the events and/or pipelines of other parts of the system.

Other uses

One historically problematic area in NServiceBus has been people forgetting to call “.LoadMessageHandlers()”. This can now be wired in automatically by a class in the UnicastBus component via the same mechanism.

A new feature coming in the next version is the “data bus”, a component which will allow sending large quantities of data through the bus without going through the messaging pipelines. This will help people get around the 4MB limit of MSMQ and, even more importantly, the much smaller 8KB limit of Azure. We will be able to introduce the functionality transparently with the same mechanism.

As an extension point, developers can now enrich the NServiceBus framework with their own capabilities and make those available via the contrib project to the community at large. This is better than the IWantToRunAtStartup interface that was only available for those using the generic host (which excluded web apps) and gives a consistent extensibility story for all uses.

Summary

Extensibility has always been a challenge when writing object-oriented code and dependency injection techniques have helped, but sometimes you need a bit more to take things to the next level while maintaining a backwards-compatible API.

Like I said, not a ground-shaking topic but something quite necessary in creating loosely-coupled frameworks and applications. Once you know it’s there, it isn’t really a big deal. If you didn’t know to do it, you may have been contorting your codebase in all kinds of ways to try to achieve similar things.

If you want to take a look at the code, you can find the SVN repository here: https://nservicebus.svn.sourceforge.net/svnroot/nservicebus/trunk/

In short, there seemed to be a hole in the development model.

Here’s an example from how nServiceBus used to do this:

builder.ConfigureComponent(typeof(HttpTransport), ComponentCallModelEnum.Singleton)
  .ConfigureProperty(”DefaultNumberOfWorkerThreads”, 10)
  .ConfigureProperty(”DefaultNumberOfSenderThreads”, 10);

The problem was that if a developer got the case of the property wrong, misspelled it in some way, or somebody later refactored/renamed that property, the system would break. It would also be very difficult to figure out why.

Then, a couple of weeks ago, it dawned on me.

This was the same problem we used to have with testing using mock objects – before we had today’s more advanced frameworks. So, the solution must be to use the same techniques. The container should give the developer an object that looks just like their class, but that would intercept all calls. Then, that interceptor could turn those into the config calls shown above. Here’s what the new config model looks like: 

HttpTransport transport = builder.ConfigureComponent<HttpTransport>
                                                   (ComponentCallModelEnum.Singleton);

transport.DefaultNumberOfSenderThreads = 10;
transport.DefaultNumberOfWorkerThreads = 10; 

Granted, you’re not going to have tons of code like this. However, for all those parameters which are factory-configured and that customers/integrators shouldn’t tinker with, it makes a difference. The biggest difference is during that time of development where you’ve gotten into preliminary integration tests but the systems components are still being “polished”.

Aside: On the current project that has adopted this model, we’ve probably saved (conservatively) about 3 months of effort with this tiny (?) thing, and this isn’t a huge project. If that’s more than you would’ve thought, well, I was surprised myself. First, understand that in the old config model, everything still compiles and unit tests pass, even though its broken.

Just consider what happens in the lab when this occurs. You have N testers that can’t test the new version, waiting. You have the person who installed the version, trying to figure out what’s wrong. They then call in one of the developers where most of the new development occurred since the previous version. They fiddle around with it, looking at exception traces and whatnot. In the best case, we’re talking about 2 hours from noticing its broken until a new version comes out fixed. Multiply that by N+3 people. Then multiply by the number of versions you do integration tests on in the lab.

Caveat: In the current version, properties must be virtual in order for this to work.

For those of you who want just this feature without nServiceBus, I’ve put up all the binaries here. For the source, you’ll need to go to here.

Let me know what you think – especially if you can take the implementation to the point where it won’t need virtual properties to work

You see, the main problem that I hadn’t been able to solve was that in order for the code to be thread-safe, you had to make sure that no code in the views would/could change entity data. One solution is not to use data-binding, which sucks, but isn’t enough to be sure. Another solution is to have all supervising-controllers clone an entity before they give it to a view. Even if you could possibly code review every line of those classes, the new guy (or old guy who forgot) will, by accident, write one new line of code that could pass an entity to a view without cloning it first. That’s not a very sustainable solution.

This thing has been bothering me for a couple of months now and I hadn’t found a way around it. Until yesterday, like I said. I was talking to somebody about threading stuff, and somehow my unconscience lobbed me this thought about AOP. Now I’m not the sharpest pencil in the pack, but I know to listen when my unconscience “speaks”.

So I set about going over what I knew about AOP – interceptors, advisors, advice, introductions, etc, etc. And then it dawned on me. I could intercept all calls to any object that implemented IView, check the parameters of those calls, and if they implemented IEntity, to clone them before passing them through.

<Homer-style WOOHOO />

The great thing is that developers don’t need to remember to clone entities – it happens automatically. The even greater thing is that this will lead developers to writing the correct kind of interaction between their views and supervising controllers.

Together with nServiceBus, this is going to make the extremely difficult problem of writing thread-safe smart clients possible.

I’ve never made use of AOP in a framework before so I’d like to get the broader community’s feedback on this before incorporating this in production. I’ve spoken with some serious AOP folks who have allayed most of my uncertainties, but I’d like to hear more. Anyway, here’s the proof of concept (that makes use of Spring).

If this turns out to be a viable solution, I think we’ll have a solid environment for building a software factory on top of. That is something that I’m really excited about. In this multi-core future (present) that is upon us, multi-threading on the client is pretty much a necessity. We need a way to get things safe and stable by default without requiring a member of the CLR team to hold our hand.

Anybody who’s interested in helping, drop a comment below.

The first is to insulate the framework and application code that I write from the choice of one dependency injection technology or another. I want the ability to switch easily from one to the other – not so much that projects go back and forth. Updating those config files is definitely not easy. However, it allows me to have “portable” framework code that is applicable to all the projects I consult on, regardless of their choice of technology.

The second has to do with NServiceBus specifically. In order to make use of duplex communication on smart clients, you need a background thread. That thread will be updating the same (model) objects as the UI thread. That means we need synchronization. I prefer to use .NET’s built-in synchronization domains in order to solve this rather thorny problem.

The only thing is that message handlers need to be in the synchronization domain so that they can easily update those objects. However, the Bus object must not be in the synchronization domain so that if we’ve received a large update from the server, we won’t be locking out the UI thread from interacting with data on the client.

Since the bus makes use of a dependency injection framework to create message handlers, this was the best place to put the code which causes message handlers to run within the synchronization domain.

Be aware that in order to enjoy this feature, you need to split up those large server updates into multiple, logical objects (that implement IMessage), but you can still publish them all in one go using the method:

void Publish(params IMessage[] messages);

And, of course, you need to set the JoinSynchronizationDomain property of the Object Builder.

I’ll have a podcast coming out on this topic soon.

You can get the code here:

Object Builder.zip

But you’ll have to get the Spring Framework code from the official site. Make sure you download RC 1.1. Then, take the binaries and copy them to the “BIN” folder of the Object Builder solution. If you’re looking to save on some “weight”, you only need “Spring.Core.dll”, “Common.Logging.dll” and “antlr.runtime.dll” for the solution to compile. You will need one of the logging implementations DLLs to get anything written to a log, obviously.

So, I’ve implemented the pattern in NHibernate, adding the following method to ISession:

As well as adding the following interface to the NHibernate package:

All this enables you to have a stronger separation between your service layer classes and your domain model class, as well as for you to express each service-level use case as a domain concept – an interface.

Once you have such an interface, you can create a fetching strategy for that use case and define exactly how deep of an object graph you want to load so that you only hit the DB once for that use case.

The nice thing is that its all configured with Spring. In other words, if you the entry for your fetching strategy class exists, you get the improved performance, if it doesn’t, you don’t. All without touching your service layer classes.

Just as an example, when I’m in the use case modeled by “ICustomer”, I want to get all the customer’s orders, and their orderlines. This would be done by having a class like this:

And the configuration would look like this (as a part of the regular spring template):

If you want to take a look at the full solution, you can find it here. For some reason, the combined file was too big for the upload on my blog so it’s split into two. Unzip both packages into the same directory. You’ll find a file called “db_scripts.sql” which contains the schema for the DB. Don’t forget to update your connection string in the “hibernate.cfg.xml”. If you’re looking for the changes I made to the NHibernate source, you can find it in the “Updated NHibernate Files” directory. The only real change is to the “SessionImpl.cs” file.

Relevant NHibernate and Spring binaries.

Source code of example.

BTW, there is some intelligent thread-safe caching going on in SessionImpl now so that you get a much smaller performance hit (in terms of code that uses reflection) on subsequent usages of the same interfaces.

Let me know what you think.

My question is about distributed topology.

The EAI-hub-and-spoke model is all about the central server. It’s useful sometimes, but there are a lot of reasons why I’m not gung-ho on using a hub as the center of the integration universe.

The ESB distributed model puts code on the endpoints. That code solves some of the messaging problems that apps face, so that apps don’t have to face them. It also solves some of the messaging problems that enterprises face, so that enterprises don’t have to face them. (I need both).

Those problems include simple coding and deployment model, pub-sub routing, reliable transport, simple transformation, and orchestration. I wonder which of these you can do in your tool, and which you are planning to do.

I’m also interested in management. How do you insure that the endpoints are correctly configured? Do you have a central configuration store? How do you propagate changes from the center to the messaging endpoints?

And here’s my response:

The important parts of NServiceBus that are independent of the distributed topology are the API and the connection to long-running workflow. This code is indeed on the endpoint. However, if you wanted to you could easily connect to something like BizTalk and do whatever you wanted there. This general idea though is to support the ESB distributed model since there’s no such things as a centralized ESB.

In terms of the capabilities you’ve mentioned, I’ve seen developers pick up the coding model in a day or two. The deployment model is just a bunch of DLLs you deploy with each endpoint. Dependency Injection is supported by www.SpringFramework.net but you can replace that with something else easily as another implementation of the ObjectBuilder interfaces.

Currently pub/sub routing is supported over regular point-to-point transports in a transport agnostic way. You also have the ability to have subscriptions be persisted so that even if a server restarts (and clients don’t, and can’t know about that) all the subscriptions will be remembered.

The reliable transport that is currently supported is MSMQ, with the option of defining per-message type if you want durable messaging (using the [Recoverable] attribute).

In terms of orchestration you get a nice model for long-running workflow that gets kicked off by messages decorated with the [StartsWorkflow] attribute, and messages that implement the IWorkflowMessage interface get automatically routed to the persistent workflow instance. You have the ability to change the storage of workflow instances easily as well. Workflows are simple classes which are easily unit-testable in that they expose a “void Handle(T message);” method for every message type (T) that is involved in the workflow.

I haven’t done anything in terms of simple transformation yet but am currently looking for the right place in the message processing pipeline to put it. I also haven’t done anything yet in terms of management.

What is currently being done management-wise on the projects that use it are the commercial options for managing configuration files in distributed environments coupled with the regular ability to restart windows services and IIS applications. I haven’t seen anything lacking in that solution yet.

If you have any questions, please don’t hesitate to send them my way – NServiceBus@UdiDahan.com.

Here are some choice quotes:

In the end, you should see bunches of projects/dlls which go together, while between the bunches there is almost no dependence whatsoever. The boundaries between bunches will almost always be an interface project/dll.

This will have the pleasant side-effect of enabling concurrent development of bunches with developers hardly ever stepping on each other’s toes. Actually, the number of projects in a given developer’s solution will probably decrease, since they no longer have to deal with all parts of the system.

Taken from So many Dlls, so little time.

And from a more recent post, One wrong DLL = 3 months gone:

Obviously, if there is less source to go through, the programmer will, on average, find the origin of the defect faster. And, as we all know, it usually takes longer to find the bug than to actually fix it.

So, by splitting up different classes and interfaces into different DLLs, we can manage dependencies in the system so that less source needs to be examined.

However, if you did want to roll up all these DLLs into fewer physical files, you could do just that using the tool ILMerge. This might make sense as a part of getting your software ready for installation. Also, access to client computers that are having problems might make you consider this.

Bottom Line

I’d say more assemblies is generally better, and merge when necessary – but don’t change your design on that account.

Ayende and I had an email conversation that started with me asking what would happen if I added an Order to a Customer’s “Orders” collection, when that collection was lazy loaded. My question was whether the addition of an element would result in NHibernate hitting the database to fill that collection. His answer was a simple “yes”. In the case where a customer can have many (millions) of Orders, that’s just not a feasible solution. The technical solution was simple – just define the Orders collection on the Customer as “inverse=true”, and then to save a new Order, just write:

Although it works, it’s not “DDD compliant”

In Ayende’s post Architecting for Performance he quoted a part of our email conversation. The conclusion I reached was that in order to design performant domain models, you need to know the kinds of data volumes you’re dealing with. It affects both internals and the API of the model – when can you assume cascade, and when not. It’s important to make these kinds of things explicit in the Domain Model’s API.

How do you make “transparent persistence” explicit?

The problem occurs around “transparent persistence”. If we were to assume that the Customer object added the Order object to its Orders collection, then we wouldn’t have to explicitly save orders it creates, so we would write service layer code like this:

On the other hand, if we designed our Domain Model around the million orders constraint, we would need to explicitly save the order, so we would write service layer code like this:

But the question remains, how do we communicate these guidelines to service layer developers from the Domain Model? There are a number of ways, but it’s important to decide on one and use it consistently. Performance and correctness require it.

Solution 1: Explicitness via Return Type

The first way is a little subtle, but you can do it with the return type of the “CreateOrder” method call. In the case where the Domain Model wishes to communicate that it handles transparent persistence by itself, have the method return “void”. Where the Domain Model wishes to communicate that it will not handle transparent persistence, have the method return the Order object created.

Another way to communicate the fact that an Order has been created that needs to be saved is with events. There are two sub-ways to do so:

Solution 2: Explicitness via Events on Domain Objects

The first is to just define the event on the customer object and have the service layer subscribe to it. It’s pretty clear that when the service layer receives a “OrderCreatedThatRequiresSaving” event, it should save the order passed in the event arguments.

The second realizes that the call to the customer object may come from some other domain object and that the service layer doesn’t necessarily know what can happen as the result of calling some method on the aggregate root. The change of state as the result of that method call may permeate the entire object graph. If each object in the graph raises its own events, its calling object will have to propagate that event to its parent – resulting in defining the same events in multiple places, and each object being aware of all things possible with its great-grandchild objects. That is clearly bad.

What [ThreadStatic] is for

So, the solution is to use thread-static events.

[Sidebar] Thread-static events are just static events defined on a static class, where each event has the ThreadStaticAttribute applied to it. This attribute is important for server-side scenarios where multiple threads will be running through the Domain Model at the same time. The easiest thread-safe way to use static data is to apply the ThreadStaticAttribute.

Solution 3: Explicitness via Static Events

Each object raises the appropriate static event according to its logic. In our example, Customer would call:

And the service layer would write:

The advantage of this solution is that it requires minimal knowledge of the Domain Model for the Service Layer to correctly work with it. It also communicates that anything that doesn’t raise an event will be persisted transparently behind the appropriate root object.

Statics and Testability

I know that many of you are wondering if I am really advocating the use of statics. The problem with most static classes is that they hurt testability because they are difficult to mock out. Often statics are used as Facades to hide some technological implementation detail. In this case, the static class is an inherent part of the Domain Model and does not serve as a Facade for anything.

When it comes to testing the Domain Model, we don’t have to mock anything out since the Domain Model is independent of all other concerns. This leaves us with unit testing at the single Domain Class level, which is pretty useless unless we’re TDD-ing the design of the Domain Model, in which case we’ll still be fiddling around with a bunch of classes at a time. Domain Models are best tested using State-Based Testing; get the objects into a given state, call a method on one of them, assert the resulting state. The static events don’t impede that kind of testing at all.

What if we used Injection instead of Statics?

Also, you’ll find that each Service Layer class will need to subscribe to all the Domain Model’s events, something that is easily handled by a base class. I will state that I have tried doing this without a static class, and injecting that singleton object into the Service Layer classes, and in that setter having them subscribe to its events. This was also pulled into a base class. The main difference was that the Dependency Injection solution required injecting that object into Domain Objects as well. Personally, I’m against injection for domain objects. So all in all, the static solution comes with less overhead than that based on injection.

Summary

In summary, beyond the “technical basics” of being aware of your data volumes and designing your Domain Model to handle each use case performantly, I’ve found these techniques useful for designing its API as well as communicating my intent around persistence transparency. So give it a try. I’d be grateful to hear your thoughts on the matter as well as what else you’ve found that works.

Related posts:

• Fetching Strategy Design – showing how to separate the concern of eager loading from both your Domain Model and your Service Layer.
• Better Domain-Driven Design Implementation – showing the basics of how valuable interfaces between your Domain Model and the Service Layer can be.
• Lazy Loading, and how messaging fixes everything again – describing the advantage of O/R mapping your message classes as well.
• Query Objects vs Methods on a Repository – discussing the scalability (in terms of number of developers and queries) of Query Objects.

In Ruby it’s easy to redefine the visibility of a method from private to public for testing purposes. This was just one small detail in his talk of course, but I started to think about how much pain I quite often go through regarding this in legacy code.

Let me just start out by saying that dealing with legacy code is far from easy. However, when writing new code, or as a part of refactoring that legacy, adding interfaces to your design can help you get around those visibility and testing issues.

For instance, if you only let “client” code access the interface, and not the implementation (probably using some kind of dependency injection), then you could leave all sorts of methods public on your concrete class without worry that the client will call them since the interface doesn’t expose them. Now that the methods on the concrete class are public, you can easily test that class.

The way to package your code to make sure this occurs follows a very simple design principle. This is much easier to put in practice on new development, but you’ll find that it isn’t that hard for legacy either. Since legacy code often doesn’t make use of interfaces, and the implementation is already packaged, and your new client code will already be separately packaged, you’re 90% there!

If you can change the legacy code, you’re actually 95% there. Just create a new package for the interface that the client code will use. Then change the legacy code to implement that interface – since the methods will be pretty much the same, it’s not that much work.

If you can’t change the legacy code, create a “wrapper” class that implements the interface and delegates the calls to the legacy code.

Finally, let me sum up by saying that I think Ruby is great. However, I think that often many advantages are attributed to anything new that may have already been possible/easy with what we already have today. Sometimes, the new stuff helps raise awareness on important issues – and then we can have great discussions on how to solve those issues with today’s (yesterday’s ?) technology

When referring to framework and tooling, “friction” is a (subjective) measure of how much the tooling gets in your way when trying to solve a specific-case problem. I’ve come to evaluate frameworks based on two rough metrics: how far the framework goes in solving the general case problem out of the box and how little friction the framework creates when you have to solve the specific-case problem yourself. When a framework finds a balance between these two areas, we call it “well designed.”

It has been my experience that when I follow my first principle of design, a good separation of logical packages occurs. These packages enable an appropriate level of flexibility by interacting via interfaces and supporting Dependency Injection. Of course, a fierce focus on assigning responsibility correctly probably makes quite a difference too. I suppose this is why I shoot for multiple smaller frameworks, than one large one. Beyond being easier to manage in terms of version control and supporting across multiple projects and products, they’re also quite a bit easier to develop.

Finally, consider that the code you’re writing is someone else’s framework/API. For people looking for more advanced API design techniques, check out fluent interfaces as well.

For any classes A and B in a system, A should interact with B through an interface.

The interface which separates two concrete classes should be packaged separately from either of those classes.

OK, so where do I go around these principles?

Well, concrete MessageHandler classes directly use concrete message classes. I don’t think of this as a problem because message classes are really just Data Transfer Objects – classes with no behavior.

So here’s the refined principle:

For any classes A and B in a system where both A and B have behavior, A should interact with B through an interface.

The interface which separates two concrete classes should be packaged separately from either of those classes.

That feels better. It holds for Views interacting with Controllers, MessageHandlers with Messages, even interactions with Domain Classes.

What do you think? Does this hold for the way you design your systems? Are there scenarios where you think this principle is too general? Let me know.

On kind of input validation is something you do as close to the user as possible for performance reasons. This includes all sorts of smart stuff you can do with JavaScript in Web scenarios. When in a Smart Client environment, you usually have greater capabilities.

When I look at the issue of validation, I see that it centers around the entity. Sometimes, it is also affected by other things, like what process are we in (as described in the comments on Ayende’s post).

So, we can model the thing that validates an entity with an interface, say, IValidator<T> where T : IEntity. This interface will have one main method: bool IsValid(T entity); and one main property: string ErrorDescription { get; }

What this allows us to do is to separate out different validation concerns into different classes, yet have all of them implement the same interface.

The next thing we’ll need is to be able to get an instance for each of the classes that is a validator for a specific kind of entity. For instance, when the NewCustomerView raises an event proclaiming that it has a Customer object ready to be saved, the Controller will want to find all classes that implement IValidator<Customer> so that it can run all the validation rules.

Luckily, the generics patch I put out for the Spring.Net Framework allows us to do this in one simple line of code:

IList<IValidator<Customer>> validators = spring.GetObjectsOfType(typeof(IValidator<Customer>));

and quite simply perform the validation as follows:

foreach(IValidator<Customer> v in validators)
  if (!v.IsValid(myCustomer))
    // notify user with v.ErrorDescription, write to log, whatever

Now, when using this in Smart Client scenarios, you will often have views that allow the user to enter in a single entity which you will then want to validate. If you have those views implement a generic interface like: IEntityView<T> where T : IEntity, then you could have a single base class implement a “Validate” method, which would perform the work above generically like so:

foreach(IValidator<T> v in spring.GetObjectsOfType(typeof(IValidator<T>)))
  if (!v.IsValid(this.Entity))
    // notify user with v.ErrorDescription

and just have your specific view call that method on the button click.

This enables all entity views to activate all the relevant custom validation logic without being tied to it. It also enables you to extend your system by adding new classes implementing the IValidator<T> interface, and have them automatically run without even changing a config file. How’s that for loose coupling?

Finally, on the issue of tying validation rules to specific processes, this can be done by extending the interface to: IValidator<T, P> where T : IEntity, P : IProcess; You then model each process with a marker interface. You then have your specific validation classes implement the above generic interface for each specific process interface. For instance, say we have a validation rule that needs to run for processes P1 (marked by IP1), and P2 (marked by IP2), but not P3 (marked by IP3), which validates entities of type E. This would be done by defining the class like so:

public class MyValidator : IValidator<E, IP1>, IValidator<E, IP2> {}

and the Controller class that would request validators for process 2 would just call:

spring.GetObjectsOfType(typeof(IValidator<T, IP2>));

That’s it. The basic principles are simple, but, as you can see, can create very powerful structures. I’ve got to say that this exemplifies one of the reasons why I love generics so much. When used with Dependency Injection, and/or Delegates, and/or Anonymous Methods, you get such a power of expression just by defining an interface. This is one of things that make coding fun for me. Or maybe I’m just wierd that way

This is something that I’ve been running into more and more and have gotten tired of working around. Here’s an example scenario:

I have an interface like ICustomer, which inherits from IEntity, another interface, and a third interface IValidator<T> where T : IEntity. I also have a class CustomerValidator which inherits from IValidator<ICustomer> and a class GenericValidator which inherits from IValidator<IEntity>.

When I ask the dependency injection framework for objects like this:

diFramework.GetObjectsOfType(typeof(IValidator<ICustomer>));

I only get back an instance of CustomerValidator, where I want to also get back an instance of GenericValidator.

The reason is that most DI frameworks use the basic “IsAssignableFrom” method to check for supporting types. This check isn’t broad enough to handle the above generics.

I’ve passed the code that does this check along to the guys at www.SpringFramework.net so that they can incorporate it into their next release. Please feel free to forward this code on to any of the other DI frameworks out there. Code is licensed under the 2-clause BSD License:

However, when your object needs to instantiate a new object at runtime the story changes slightly. For instance, you wouldn’t want your UI controller to have a reference to a concrete form so that you could better test it. However, there must be some other way to inject that dependency – neither a setter or a constructor argument.

In my opinion, this is no longer DI, but rather something of a deferred object construction. Instead of your code “newing” up the concrete class, you defer that to something else, the DI framework. Indeed, all the frameworks I’m aware of support this.

One of the most common ways this construction is done is for your code to ask for the object by name. Since the DI framework needs a way to identify objects/classes for wiring purposes, every object gets a name in the config file. So, in order to get a new instance of the customer form you would write code like this:

ICustomerForm f = springContext.GetObject(”CustomerForm”) as ICustomerForm;

Where, in the config file, CustomerForm is defined to be a single-call object, meaning that a new instance is created every time “GetObject” is called for it.

And this works great. So you go and implement all your UI controllers similarly. In fact, any place you need to create an object, you do the same – all your programmers do. And you all pat yourselves on the back what a fantastically loosely-coupled system you’ve created.

Until, one day, that very same code blows up. The call to GetObject returns null. You check the config file, the entry is there. You check that class file that it references, the Dlls are there. You check constructor parameters, and everything’s fine. You go and check it on a different machine and it works. Go back to the first machine, it doesn’t.

AAAAAARRRRRRRGGGGGGGHHHHHH!!!!

Hours later, somebody (maybe a tester) walks by and sees you peering at the config file looking for salvation. He comments “I thought the ‘f’ in Customerform was supposed to be uppercase”. You shout, and then cry, and laugh, some more crying, make the fix, and go home.

Hopefully, you reach the same conclusion that I did. Those strings are evil. The compiler does not check them. Neither do the unit tests. Chances are the acceptance tests don’t either. You must never embed a string in your source code which must be identical to some other string outside the source for the system to work. Alas, the string passed to “GetObject” is just such a string.

The solution is simple, once you’ve returned to the problem. Since the UI controller only knows about ICustomerForm, it must ask the DI framework to give it the object that implements ICustomerForm. That code knows nothing else, so it cannot ask for anything else. Since, by design, in a given deployment you will only have one object that fulfills the role of ICustomerForm, you’re all set.

Ay, there’s the rub.

In your design, the interfaces whose implementations you will need to be able to create in a single-call fashion must be such that they do not get used in different, single-call scenarios. Otherwise, when asking for the object who implements ICustomerForm, you could get several, but only one of them is correct (not that you can know at runtime which one). Therein is the constraint on the solution to the correct problem.

The code for spring.net, wrapped in IObjectBuilder, looks like this:

    public class Builder : IBuilder
    {
        #region IBuilder Members

        public object Build(Type interfaceType)
        {
            Spring.Context.IApplicationContext ctx = Spring.Context.Support.ContextRegistry.GetContext();

            System.Collections.IDictionary dict = ctx.GetObjectsOfType(interfaceType, true, false);

            System.Diagnostics.Debug.Assert(dict.Count == 1,
                "Should only be one type that implements " + interfaceType.FullName,
                "Types found: " + this.GetTypeNames(dict.Values));

            System.Collections.IDictionaryEnumerator de = dict.GetEnumerator();
            return (de.MoveNext() ? de.Value : null);
        }

        public InterfaceType Build<InterfaceType>() where InterfaceType : class
        {
            return this.Build(typeof(InterfaceType)) as InterfaceType;
        }

        #endregion

        private string GetTypeNames(System.Collections.ICollection iCollection)
        {
            StringBuilder sb = new StringBuilder();

            foreach (Type t in iCollection)
            { sb.Append(t.FullName); sb.Append(", "); }

            return sb.ToString();
        }
    }

Anyway, like the title says, careful with those injections. You wouldn’t want to introduce other, hidden (string-based) dependencies as a result of removing todays (class-based) ones.

I think that it’s a reasonable and expected response. What’s wrong with what we’re doing now? How is dividing it up more going to make it better?

Before I get into the reasoning, the end result needs to be examined.

Have you ever had a case where you used a dll (let’s call it A) which depended on B, which in turn depended on C. In your project/dll you also use C directly. I’d be willing to bet that almost everyone has run into this scenario. This is the path to dll hell, more appropriately named versioning hell. It is at the root of many an integration gone bad. Reminds me of the commercials “when you sleep with your friend, your also sleeping with all your friend’s friends, and their friends…” and so on.

The hell above is the result of sloppiness. Sloppiness with dependencies. If two classes are independent of each other, and do not provide different implementations of the same interface, think twice about putting them in the same project/dll. Minimizing dependencies is the bread and butter of loose coupling. Break dependence on implementations by introducing interfaces in a separate project/dll.

Do it over, and over, and over again.

* You don’t necessarily have to code, in order to refactor your design.

In the end, you should see bunches of projects/dlls which go together, while between the bunches there is almost no dependence whatsoever. The boundaries between bunches will almost always be an interface project/dll.

This will have the pleasant side-effect of enabling concurrent development of bunches with developers hardly ever stepping on each other’s toes. Actually, the number of projects in a given developer’s solution will probably decrease, since they no longer have to deal with all parts of the system.

Bottom line: design is about managing dependencies between classes and dlls.

There is a different, more OO way of handling this. By separating out the interface of the class you want to be lazy loaded – make an IPerson interface – and have the client code be tied to that. In that way, your dependency injection container (Spring, for example) could instantiate an implementation that handles lazy loading without the client having to know about it. This implementation is absolutely something that could be handled by an OR mapping tool.

So, I suppose that even some of the more difficult problems of OR mapping could be handled. All that is needed is not to add more to the tool itself, but rather to more formally structure how to work with it. My opinion, anyway.

Update

The next part around the discussion about lazy loading and fetching strategies.