I found myself looking for a Dependency Injection tool / container a few days ago. I've known about DI for some time now and have used it a lot even without Test Driven Development, so the need for DI in TDD was quite apparent to me. I did some brief searching and blog reviewing and found that there are a few common DI frameworks for .NET including Spring.NET, StructureMap, and some other homebrewed items. Having reviewed the basic design and usage of both Spring.NET and StructureMap, I decided that what they implement is too feature rich for my needs, right now. The end result is that i wanted to create a simple DI container where I can register a Type or an Instance of a type, when a request is made to the DI registry.
To help boost my confidence and abilities in TDD, I decided that I wanted to implement my DI tool using TDD. Having gone through the motions now, I think I have a fairly good understanding of Test Driven Development from both a theoretical standpoint and an implementation standpoint. I've found myself able to start coding, to a certain degree, with my unit tests. Create a set of code that represents what I want the code to actually look like, then create the code to match that design.
Now, I'm not stuck on the following point: Data-Centric development vs Process-Centric development. I believe I was successful in my TDD efforts for this DI tool specifically because this was a process-centric tool that I was writing. I was able to design how the code should work in my unit tests prior to actually writing the code - I was working within the Domain of my project and creating domain specific objects with methods properties, etc.
The issue that I'm facing is not the DI tool itself, but the dichotomy between data-centric applications and process-centric applications. In my daily development efforts at work, I write 80% + data-centric applications. I focus on mapping entities into database system, and providing data entry screens via the web or winforms. My entire development life has focused on this, actually. I have CodeSmith templates that do nothing but map a database table directly to my entity structures, business layers, and data access layers. My entities so often coincide with the table structure that I sometimes have a hard time helping my coworkers understand that an object doesn't have to map directly to a table structure.
The entity structure we use is a customized version of Rocky Lhotka's CSLA, with the data access layer and enforced parent-child relationships removed. This core structure makes building data-centric applications extremely easy, because it provides all of the core databinding, method overloads, and other data-centric business features that we need. However, I'm finding myself stuck in a situation where I don't know how to do TDD with CSLA. I understand the need to abstract out the data access code that that we can inject a mock Data Access Layer in for TDD - this is actually the primary reason that i wrote my DI tool. So now I've got an entity structure that supports the DI that I need, and I can inject any mock object I need into my model, for TDD... but I can't design my object model the way that I want, because my core structure already has so many of the databinding, collection, and other interfaces built into it.
I want to write code for a training tracking system like this:
Person.AddCertification(new Certification());
But I am forced to write code like this:
Person.Certifications.Add(new Certification());
I know this may seem like a trivial example, and it is. The difference between "AddCertification" and "Certifications.Add" is only minor, but the underlying problem is a significant difference in style and how code is written. The method that i want to write assumes that the Person object knows directly about adding certificates and storing them (associating them) with the person. The second method, however, assumes that a certification collection is directly responsible for associating the certifications with the person - thus the person only knows if it has a certification collection, but does not know about the actual certifications.
Which way is correct? Honestly - I don't know... I'm a little lost at this point. I want to write Person.AddCertification(), but I am constrained by my entity framework, to write Person.Certifications.Add(). Sure, I could add the .AddCertification method to the person object, but that provides little benefit. If i put any logic in this method that is needed when adding a certification, I am opening up a large whole in my API because the .Certifications property and object still exists on the person. I suppose I could make the Certifications property private to Person, but then how do I retrieve the list of certifications when I need to work with it?
...
Can anyone provide some direction? I need to answer these questions for myself before I can begin answering them for my team, and I have to start answering the questions soon.