The Repository Factory - Try It, Use It, Contribute!

  • Article

This news isn't exactly hot of the presses, but it probably flew under the radar for many of you so I thought it was worth a blog post. The first official release of the Repository Factory is now available to download from CodePlex. Not sure what this is or why you might care? Read on...

Some history

The Repository Factory isn't actually a brand new release; it's an update to the Data Access Guidance Package which was a component of the first two releases of the Web Service Software Factory. The purpose of Data Access Guidance Package, and now the Repository Factory, is to automate many of the common development tasks required when building data access layers in ADO.NET. Specifically, it contains recipes that automate the following:

  • Generating business entity classes using metadata from database schema definitions
  • Generating stored procedures for common CRUD operations, from database schema definitions
  • Generating data access classes, using the Repository pattern, to retrieve and persist business entities from the database.

While the Repository Factory plays a similar role to Object-Relational Mapping solutions such as NHibernate, the philosophy behind it is quite different. Rather than attempting to abstract away the mechanics of the data access layer, the Repository Factory aims to generate data access layer code that looks the same as what you would write by hand. Also, there is absolutely no expectation that the factory is able to generate all of the code you need. While the generated code is a great accelerator, it won't include a number of important things such as converting object hierarchies to and from related tables, so you'll almost certainly need to extend the generated code by hand.

As for why the team chose to spin off this solution from the Web Service Software Factory into its own deliverable, that's a bit of a long story. Right from the start of the WSSF project there were discussions on whether we should focus purely on the service interface layer, or whether we should take a more holistic approach and consider all of the functionality typically included in service-oriented applications. I successfully argued for the latter, but now that I've left it looks like the pendulum has swung back around :-). Actually there is another good reason why they made this decision, which is that the team plans to focus their efforts around data access guidance on LINQ and ADO.NET Entities, and didn't feel that they had enough bandwidth to continue to evolve their ADO.NET guidance. So by spinning the Repository Factory out to CodePlex, the community is now able to move it forward on their own.

What's new?

I wasn't involved in the development of Repository Factory since it was spun off, so I'm just going by what I've found while playing with the new release and what I've seen on the CodePlex site. From what I've seen, the changes from the original DAGP are small but very worthwhile. The organisation and implementation of the generated code has been cleaned up, for example the generated repositories all implement interfaces to allow for multiple implementations (eg for unit testing purposes).

There have also been a number of changes to the recipes and wizards. For example, UI in the wizards for generating repository classes have been reworked to have more pages with fewer controls. These changes are all nice, however there are two other changes in the wizard for generating repository classes that are enough on their own to justify an upgrade:

  1. Any business entity properties which have the same name and type as stored procedure parameters are mapped automatically, eliminating about 73 clicks and the onset of RSI
  2. The wizard will remember the operations and mappings you generated previously, making it possible to re-run the wizard to create new operations or modify existing ones.

My thoughts

I'm really glad to see this project move ahead, and want to thank Chris Tavares and the team for their great work on the new release. While I love the new features, there are a few rough spots:

  1. On my box, the MSI for installing the guidance package returned an error and refused to complete. Also the manual registration required quite a few awkward steps. I know that guidance package installation is often painful and it may be an issue with GAX or my machine, rather than with the Repository Factory. Still I know everybody finds these kinds of usability problems very frustrating.
  2. Some of the new wizard UIs are still a bit rough around the edges
  3. The documentation links all point to WSSF pages rather than Repository Factory pages
  4. It would have been nice to see some more functional improvements such as support for object hierarchies or more control over concurrency models. Still I know these problems are hard to solve, so there is an argument for keeping the solution simpler rather than doing a complex task badly.

That said, I know this release was essentially community-driven with very few resources. Which brings me to my next topic:

Get involved!

I'm very excited to see the growth of community-driven projects for the .NET platform. While the patterns & practices team does fulfil a similar role that is often played by OSS projects on other platforms, I think people are beginning to understand that p&p is a complement to, rather than a replacement for community-driven OSS projects. The Repository Factory is a very interesting example, since it was started by p&p but has now been handed over to the community for further evolution.

I'm sure everyone would love to see initiatives like this succeed, but of course it doesn't happen unless people sign up to get involved in the project - whether as a coordinator, developer, tester or doc writer. If you think you've got what it takes, the team would love to hear from you.