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

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.

Comments

• Anonymous
  October 11, 2007
  PingBack from http://noocyte.wordpress.com/2007/10/11/tom-hollanders-blog-the-repository-factory-try-it-use-it-contribute/

• Anonymous
  October 12, 2007
  It might be helpful to understand how this is different than what will be delivered in LINQ to SQL. I also think that while it is nice to have these ORM tools, the 'O' is misleading.  Just because I have a table called 'Customer' doesn't mean it should be a 'Customer' object; in otherwords a table != object.  A Customer in a business application has rules and behavior that may not be part of the 'Customer' table.  An object should model the behavior of a real world object. An example would be that you can't sell cable services to a Customer who is currently in the financial collections department.  Or that a customer can only have certain groups of cable channels bundled together dependent on their location.  Could you do this with some slick joins to other tables in other databases in the enterprise, sure - but it's a headache. I think you or I would abstract this kind of business behavior into a Business Facade or Manager or use a business modeling framework such as CSLA.  The problem is that our culture and the marketing of 'just map your table to a data grid' encourages young developers to focus on ERD driven development with tools such as these and skip the business behavior side of things all together and any behavior ends up in the windows form or code behind of a web page if they can't find a way to make it a part of the database structure.  This is a very bad thing when these kids start working on real enterprise applications where the encapsulation of business rules can't simply be put into a bunch of tables as null checks and foreign key constraints and putting the rules in a place where they aren't reusable is problem.  Our young developers out there should be focusing on use cases and behavior of object, but instead the first thing they do is come up with an ERD.  Worry about how the objects behave and interact with each other, then worry about how you're going to store it. I'd really like to see Microsoft start moving towards putting out tools that encourage development of objects that focus on the behavior of data instead of the ability to quickly get it and tie it to a data grid.

• Anonymous
  October 12, 2007
  bri189a: The fact that you don't represent the exact same data and rules in an object model and a database is what makes this a complex problem. But these types of solutions are designed for cases where you have one representation of a concept in objects and one in the database, and you need to map between the two. LINQ to SQL supports some of the same scenarios as the Repository Factory and other ORM solutions, but using a very different approach. The Repository Factory is just about generating ADO.NET code, so you wouldn't use it in a LINQ solution. Tom

• Anonymous
  October 13, 2007
  Thanks for the clarification. Looking forward to giving it a spin.

• Anonymous
  April 14, 2016
  Hi Tom,We only recently migrated from Visual Studio 2008 to VS2015 and looking for anyone who may have any information regarding this repository factory working in VS 2015. If you have any site or contcats that you could pass on then that would be great.Cheers,Brendan