Dependency Injection vs. Mobile Objects

Bob Matthew posted on Thursday, April 10, 2008

To preface, I would like to get some opinions from some of the regular contributors to this forum regarding this topic and potential workarounds you may be using to address the issue.

Let me also state that we are die-hard CSLA developers in my shop. The advantages of the framework are tremendous and cannot be ignored.

Earlier I posted regarding what appears to be an incompatibility between mobile objects (objects that inherit from Business*Base) and dependency injection techniques as outlined in inversion of control methodologies.

We have determined that mobile objects can easily take advantage of a service locator, both for resolving the mobile objects themselves or dependencies inside of the mobile objects. However, the service locator technique itself has several limitations: http://ubik.com.au/article/named/service_locator_vs_dependency_injection

Now for the meat and potatoes:

The reasons CSLA-derived mobile/business objects cannot take advantage of dependency injection are twofold:

DataPortal.Create<> & Fetch<> use the default, parameterless constructor of the object such that no injection can take place. This could potentially be solved using “setter” injection rather than constructor injection.
Many of the dependencies that a mobile object has, such as a database connection, LINQ’s DataContext, or other related services cannot be serialized and therefore are unable to travel across the wire with the mobile object.

Thus, when a mobile object has a dependency, the only way to get an instance of a service interface without direct instantiation is to call a global/static service locator.

Or am I completely wrong? Have any of you guys been able to implement dependency injection into your CSLA-derived business objects?

Thanks!

Boris replied on Saturday, April 12, 2008

Bob,

I believe we’ve already started this discussion in another posting here …

On the topic:

I felt the same a month ago, and then I discovered StructureMap.

I did a lot of prototyping and was really pleased with the results.

Csla + StructureMap can work, and StructureMap is not that hard to master either…

I’d encourage you to try StructureMap (I’m using the latest 2.5 version from svn)

You just have to be clear what is it exactly you want to do...

- Some dependencies are good!

- Some you have to break for the sake of Unit Tests, and

- Some you have to break to be able to introduce totally new behavior at runtime for example…

I really don’t have the time to post a complete CSLA example now, and I guess I’m not 100% what you want to do, but if you ask a specific question I’ll spend some time putting something together soon.

BTW:

Rhino + StructureMap really changes how you write Unit Tests, and they can really be Unit, because you can inject mocks of just about anything…

This is the book that really helped me understand this:

http://monkeys.codebetter.com/blogs/karlseguin/archive/2008/01/02/foundations-of-programming-pdf.aspx

(Concentrate on: Foundations of Programming - pt 4 – Dependency Injection)

Cheers!

Boris replied on Saturday, April 12, 2008

Here is the simplest example that will get you started with StructureMap:
http://frickinsweet.com/ryanlanciaux.com/post/Very-Quick-and-Simple-Dependency-Injection-with-StructureMap.aspx

Then just follow the examples around DI in the book from my previous post...

You may have to introduce interfaces around your BOs once you get to know StructureMap, in order to be able to configure the PlugginType & PluggedType, but I hope that won't be a problem.

I also found that static methods are not a stopper either. Thanks nermin!!