…run without the database — Active Record implementations like Trade trade = new Trade(“tradeId”) where the constructor immediately reaches into the database to grab the rest of its properties. One of the reasons that I won’t use the Entity Framework by choice is the lazy fetch implementation: invoice.Items.Load(). I understand their reasoning for doing this, but it totally screws up unit testing.
…run without a configuration file — Extra stuff that has to be copied around and valid for the code to work
…run without needing half of the rest of the application — “Trade trade = new Trade(“tradeId”, tradeRepository)” is no bueno
…be at least partially set up in a few lines of code — An ObjectMother can help tremendously. Yeah, an ObjectMother is often times deoderant, but still…
and just for any Java folks that might have stumbled into this accidentally.
…run without some sort of heavyweight container*
But Jeremy, I just needed to “Git ‘R Done!” and I don’t have time to worry about ivory tower things like separation of concerns! Careful design *is* pragmatic. Keeping service and infrastructure concerns out of your domain objects should help in the “Git ‘R Done” category, because:
Your business logic lives in the domain objects. It’s more efficient and safer to be able to work on domain logic without other services getting in the way. I want to write and read code that works with domain concepts. I want to work on one thing at a time, and in this case that one thing is domain logic. More signal and less noise makes it easier to verify the business logic code by inspection, which is good considering that that code is very likely to change.
Much of the rest of the system reacts to and interacts with your domain objects. When I’m working with a controller class or a repository class I want to develop and test those things without incurring a heavy tax from setting up connected domain objects with whatever container.
*Of course, the great thing about being in .Net is that the Java guys bump into most of the problems first since they’re always a year or two ahead. Just pay attention to what causes the Java community pain and avoid it when some clown tries to introduce the pain into .Net.