Repository Factory Example
The Microsoft Patterns and Practices Teams need to change their thinking about Enterprise Library.
Enterprise Library needs to be thought of as a provider of services and not a dependency in their various software factories.
This came up again today as I was playing with the Repository Factory and noticed it had a dependency on the old Enterprise Library version 3.0 and not the latest and greatest version 3.1. This will be fixed quickly I am sure, but it is just another example of how the software factories continue to lag behind in the versions of Enterprise Library they are dependent on, making it difficult for developers to use them.
More importantly, however, why should the software factories be dependent on Enterprise Library at all? Why can’t the Data Access Application Block, for example, be a pluggable database helper provider to the Repository Factory?
There are numerous benefits to thinking of Enterprise Library as a provider:
- We don’t have to deal with the software factories lagging behind the latest version of Enteprise Library. Enough said.
- Opens up the software factories to people who either don’t like, can’t deploy, or have their own modified versions of Enterprise Library.
- Allows us to more easily create our own custom providers to plug into the software factories.
Using the above example, the Repository Factory is an ideal place to abstract out the Enterprise Library Data Access Application Block and make it a provider instead of a dependency. The DAAB can be the default provider and making it a provider should not make the Repository Factory any more or less difficult to work with. Seems like a no-brainer.
