Thanks for the question(s).

We’re creating a repository for each domain entity because long-term we know we will need to have repository methods that are more robust than the CRUD we are starting with. The (example) signature of…

public class CustomerRepository : ICustomerRepository, NHRepository< Customer >

…is like that because I want to have a repository that will eventually evolve to handle just customers *in a domain-centric manner*.

Consumers of this will take a dependency only on the ICustomerRepository abstraction which will expose customer-centric methods only (e.g., .SaveCustomer(Customer) rather than .Save(T). The implementation will use the generically-defined methods of the base class to get its work done under the covers, enabling me to leverage the power of the base class without exposing the 100s of methods it offers as being part of the actual repoitory’s implementation (ICustomerRepository won’t expose the CRUD-centric methods of the NHRepository< T > base class so consumers won’t be aware/bothered by them).

Essentially, its this: if you just do…

public class Repostitory< T > : NHRepository< T >

…then you end up with a HUGE surface area for your repositories that offer up all kinds of CRUD-centric methods that aren’t expressed in domain terms, slowly leading to what I call ‘API pollution’ where your repository is just too API-rich for anyone to know how to consume/interact with without some kind of giant API reference guide being provided to them.

One of the big things that can (often) be hard to get your head around in Domain Driven Design is that even though the ‘role’ of the repository is to provide ‘persistence services’ for your domain, its also got the role of *abstracting* persistence from the rest of your domain and that (usually) means not just wrapping CRUD methods in a repository object but also expressing the persitence of domain objects in domain terms.

As a concrete example of this, consider the following two methods, each of which MIGHT result in the same action, deleting a customer from the system:

CustomerRepository.Delete(Customer);
CustomerRepository.RetireCustomer(Customer);

Both might (in the end) result in the customer being deleted, but the first one is expressed in terms the DBA will understand and the second one is expressed in terms your domain experts will (hopefully) understand.

In fact, CustomerRepository.RetireCustomer(Customer) might even just flag the customer as ‘inactive’ in the system and *update* the record instead of even performing an actual delete, but the point is that you wouldn’t actually have to CARE about that if you called CustomerRepository.RetireCustomer(Customer).

I hope this helps clarify where I’m coming from on this; I can agree with you that there may well be a YAGNI issue creeping in here, but my own personal experience has taught me that eventually IAGNA (I Am Gonna Need It) and so I’m proactively adding it before its immediately obvious that I will be requiring it.

Thanks again for the comments~!

-Steve B.

“public class GenericRepository : Rhino.Commons.NHRepository
{
}”

Each of the repositories are doing pretty much the same functions i.e. save, get, find etc.

Yet we are creating a repository every time and using the base class to execute the function. This requires manually adding the repository and interfaces for entities which may not ever require any additional methods to persist data. This smells of a DRY (Don’t Repeat Yourself) violation.

Surely we could register a generic repository with windsor and use generics to pass in the entity. Something like:

public class GenericRepository : Rhino.Commons.NHRepository
{
}

container.Register(Component.For(typeof(IRepository)).ImplementedBy(typeof(GenericRepository)));

and then have access to it via:
IRepository repository = IoC.Container.Resolve<IRepository>();

My issue seems to be how to handle the UnitOfWork??

I would rather not have to create a repository for every entity and would rather create a specific repository for an entity that requires extended methods.

So, is there a workaround to handle the UnitOfWork? I am sure this is a common concern.

Sam

Thanks for the feedback; glad you are enjoying the content and finding value in it.

Re: the Microdesk.Domain.Foundation classes, see this post for an update (I’ve gone OSS with the code now)…

http://unhandled-exceptions.com/blog/index.php/2009/03/16/proteus-unit-test-utility-and-domain-foundation-code-goes-oss/

HTH,

-Steve B.

love the casts and very thankful for effort. How we doing with the microdesk.domain.foundation classes? perhaps even a stripped down version just to highlight the db load & save functionality?

love your work

Chev

Technically, the unit test utility supports only DBs that the underlying NDbUnit core library provides support for so you could actually develop a patch RIGHT NOW for NDbUnit and I could apply that to the trunk and then extend the unit test utility to leverage this new DB type quite easily.

The Unit Test Utility’s list of supported DBs is just an abstraction-wrapper around the NDbUnit support for diff DBs.

This will likely be happening within the next month at the latest, but as part of the process the namespaces will be changing to remove any reference to my employer.

This will be true of the Domain Foundation library as well as the Unit Test Utility.

Stay tuned for more info~!

There is one open question about Microdesk.Domain.Foundation. Before 3-4 months you said that there is a little hope your blog subscribers and all other people to have the source of this lib. What is the status?

And let the force be with you!

Glad to have helped. As for you remainder exception stack there, try the Microdesk.Domain.Foundation.dll found in the last available code download and that issue is (should be) resolved in the binary for that found in the /lib/ folder of the download ZIP.

I screwed up and failed to define the base class’ props as virtual until later — my oversight!