Believe I found the article (googletesting.blogspot.com/…/defeat-static-cling.html) you were referring to.  That is a great article.  Wish I would have seen that a while ago.  Thanks.

With Aarons series of comments walking me through these topics, I believe this is clearing up and I definitely take your point.

Spring, windsor, whatever other ioc container shouldn’t be used to create classes that represent the domain/state, they should only be concerned with providing services…

I hadn’t really taken that into account.

I’ll have to give your Register example a run and see how things pan out. I’m not sure I see the increased coupling caused by static methods, but I will keep my eyes open as I attemp to understand and incorporate DDD into my repertoire.

Regarding property injection (getters/setters) I’d recommend steering away from that too. They are typically used for optional dependencies. An object should be able to function after its constructed.

And yes, unit testing tools (Nunit, mocking, whatever) are very useful for integration tests. They should be called testing tools rather than unit testing tools, but too late to change that

Glad to hear about the VerifyAll thing… it’s currently one of my biggest annoyances with Mock frameworks–the poor guidance on mock vs. stub.

Static methods greatly increase coupling. You mention that they are there for “ease of use by the developer”. The unforutnate bit about that is by making it that easy you are likely to end up with a web of class dependencies and you can quickly get to an unmanageable mess. When your dependencies are explicit and few your code is even more navigable.

SRP on the BLL can be a bit awkward, you basically say that the responsibility is to act like a Whatever entity. If in your business domain entities have multiple responsibilites you either need to accept that or separate those entities into role based entities. You’d especially do this if you have a bounded context between the roles or they’re separate domains.

SRP on the Controller is simple. Its responsibility is to delegate an action to the appropriate application service and do any adapting it needs to do to the parameters.

About implementing Register, I’d probably just delegate to a factory to do the creation, save the user in the repository, and then delegate to an email sender to thank them. You could also fire a user registered message that an email sender would listen to and send the thank you email. That sort of architecture is very nice and its something we’re trying to move to.

Aaron (and now John),

Semantics… You are correct, I should be more clear. I should say, I find the tools for Unit Testing helpful in running Integration Tests.

VerifyAll on the container… Oversight during copy paste. I would not and don’t include that assertion throughout. There are unit tests specifically around my concrete container implementation, all one of them.

Single Responsibility… I would say that the API used throughout my application(s) do diverge from the Domain object purist vision. I could easily see someone saying that my Customer object does too much orchestration, but I would vehemently argue that it does not leave the bounds of OO. Do I use a CustomerRepository to get a customer, yes, inside my Customer.GetById static method. I find it makes my API compact and navigable.

To the same point, Member.Register is a static method. It isn’t fully necessary for that to even exist and I could use DependencyInjection as it, internally, resolves an IRegistrationManager instance to do it’s bidding. Member.Register is simply their for ease of use by the developer.

Can I ask how you would recommend implementing the Register (my create) method or scenerio? For the sake of the discussion, say Register simply Creates a member instances, sends them an email thanking them, and saves that instance to the Repository backing.

Can I also ask how you feel the SRP applies to a BLL or Controller?

What constructor injection gives you is removes your dependency on a specific implementation of your interface. With Constructor Injection your NotificationManager can be changed for your testing or if you need to change it later.

Also, if your objects are indeed “busy” then you may want to consider if you’re violating Single Responsibility Principle / Separation of Concerns. It could be that your behavior should be broken up into smaller classes who have their own dependencies.

Single Responsibility Principle states that an object “should have one reason to change.” Having a lot of dependencies in a class is my first smell that I’m voilating this principle and I need to break up functionality.