Consuming Software Factories
It used to be that Software Factories were just a pipe dream. An intellectual exercise that really smart people like Jack Greenfield explored; not a practical tool that could be added to average Joe developer’s toolset. Six months ago, I might have agreed with that sentiment. But I am convinced that software factories are something you should be looking into right now.
For the past six months I have been working with both Smart Client Software factory (SCSF) and Web Services Software factory (WSSF) to build a composite windows forms application that consumes services built using Windows Communication Foundation (WCF). I have used both of these software factories to generate thousands of lines of code and save weeks of coding. More importantly, they have increased the overall quality of the application we have been building by forcing developers to not only use certain design patterns, but use them correctly.
The Patterns and practices group at Microsoft is probably best known for Enterprise Library, a collection of “application blocks” that solved specific problems like data access, exception handling, logging and validation. Since then, they have released five software factories including the mobile client software factory, smart client software factory, web client software factory, web service software factory and the application block software factory. These factories are all built on top of the Guidance Automation Extensions/Toolkit and in the case of web service software factory, the Domain Specific Languages toolkit. Creating your own software factories may is not a trivial exercise, and not one I would consider lightly, but this shouldn’t stop you from looking at what the prefabricated factories that already exist have to offer.
The existing patterns and practices factories require you to buy into their core architectural principles and underlying design patterns. They generate code and automate a lot of the plumbing that is not terribly exciting to code, but adds to robustness of the architecture. The real value for me is that it makes it easy not to be lazy when it comes to following these design patterns. For me it is way too easy to be lazy and take shortcuts when trying to adhere to design patterns. A pattern might call for implementing an extra interface, when it’s easy to cheat and just code the class by itself. When the software factory generates the code, it’s a moot point. It is done the right way and you’re never tempted to cut corners.
I’ll be discussing my experiences with the software factories, the architectures and design patterns they automate at the next Fairfield/Westchester .Net Users Group meeting on August 5th.