Time to look back on the last eight or so months of building and (finally) shipping Service Factory: Modeling Edition. I thought it might be interesting to think back to some of the things that caught us unawares when building a model centric factory using DSLs on top of GAT/GAX.
Bob (Dev) and Wojtek (Architect) gave a presentation on this at the p&p Summit yesterday. Here are the key takeaways from that in no particular order:
To paraphrase Bill Clinton “It’s the model stupid”. Changes to the DSL will ripple throughout your whole application! Changes to DSLs become very painful especially as the refactoring tools don’t really help you. It’s worth trying to do some thinking about your models up front; what they look like, how they’ll be used and what the model elements are called.
Testing DSLs is hard but not impossible. We wrote a lot of tests against the DSL In Memory Store (IMS). These are more like acceptance tests as the IMS isn’t easy to mock so the test has to create a real DSL IMS and modify it. However it does allow developers to write tests that are somewhat “under the UI glass”. You can see these in the Service Factory unit tests and I’ll be blogging more about this soon with some examples.
Tooling for authoring T4 templates is currently pretty minimal. Clarius has just released a T4 editor but we didn’t have the chance to use this during our development. Probably worth checking out, it might save you a lot of time!
Writing setup for a large factory is hard. Putting it off is even more painful! It’ll also reduce your ability to be agile and deliver software throughout the development process. The DSL Toolkit includes a setup project that generates an MSI from WiX scripts. We butchered these to create a single install for the guidance package and the DSLs. Jezz Santos has just published a couple of papers on building and packaging DSL based factories.
DSLs install assemblies into the GAC. In my opinion this is less than ideal but that’s the way it is. This means that you’ll have to sign and GAC your dependent assemblies too. The next VS SDK release also includes some improvements and fixes to the DSL setup project.
Reuse our infrastructure. Much of the work we did around Service Factory was around writing a model project to hold models and making the factory extensible for those who wanted to extend it. About 60% of out time went into this. We effectively already had the assets required to build the factory as these were developed for the previous version. We invested heavily here and you’d be wise to leverage this investment!
Don’t forget the lessons of agile even when they seem hard. Some of the things we struggled with included: automating your build, code compile through to the MSI and automated testing of the whole product.