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...
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:
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.
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:
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:
That said, I know this release was essentially community-driven with very few resources. Which brings me to my next topic:
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.
PingBack from http://noocyte.wordpress.com/2007/10/11/tom-hollanders-blog-the-repository-factory-try-it-use-it-contribute/
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.
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.
Thanks for the clarification. Looking forward to giving it a spin.