I’m increasingly questioned about how much code-generation we employ when we’re developing our own solutions upon Cairngorm; let me address this point with a look to the past, the present, and the future.
The Past – From UML to Code Generation for the Mother of Cairngorm
Way back in the past (1999-2000 timeframe) I was a huge advocate of UML and roundtrip engineering; in fact some of my now Adobe Consulting colleagues were colleagues in a past-life, where we were ardent users of the Together UML tool for Java. Together were acquired by Borland, and Together UML now ships with Borland IDEs I believe.
Around the same time I began to sip from the agile firehose, I became less interested in UML modelling and model-driven development techniques. It was around this same time that I first was exposed to the Core J2EE Design Patterns from the Java One presentations by Alur, Crupi and Malks, and developed my first architectural framework using these patterns in Java. We called the framework "Mesh" (as in a wireframe mesh for the application, remember this was before struts, but same idea) and found ourselves laboriously writing lots and lots of repetitive "handle-turning" code. Mesh was the mother of Cairngorm I guess, in that Cairngorm took a subset of the design patterns that we leveraged in the Java world. In Cairngorm, we discarded the Data Access Object (DAO) pattern, the Business Delegate became a much simpler facade onto server-calls, as opposed to an almost object-to-relational bridge between the Java value-object world and the JDBC PreparedStatement and ResultSet world for Create, Read, Update and Delete methods. And of course, the value objects mapped very closely to the underlying database structure, as the DAO pattern adapted tables to objects.
We found that any story (feature/use-case) we picked up for development would inevitably be a bottom-up development of "add/augment a database table, update the value object definition, create a new DAO if it was a new table or view on the database, or tediously update lots of SQL queries and iteration over ResultSets if we were simply adding columns to a table, write new methods on the DAO, and then write new methods on the appropriate Business Delegate class to call the new DAO methods, adapting ResultSets into value objects and value object graphs. Only then would the story-specific fun begin, as we implemented Command classes and JSP to render the view. Boring, boring, boring.
With all this tedium, I turned to code generation of the value objects by JDBC introspection of the database metadata (creating value objects per table, and attributes on value objects according to columns in the table). I’d then code generate the DAO classes, all the CRUD operations and queries, and the business delegate methods for each DAO method. It was all very crude (perl initially, Java eventually) code generation, and inevitably we’d step in and do some hand-coding or optimisations to the code anyway, which meant we then didn’t want to rerun the codegen (it wasn’t as clever as being round-trip code generation).
I’d argue that with all this tedious VO, DAO and Business Delegates upon a database tier, the effort for code-generation just about paid off for us.
If you’re interested in this kind of approach, from database through Java-tier all the way to creating client-side code (not Cairngorm based) and a view, the team at Farata Systems have created DAOFlex that will do exactly this kind of code generation, much more elegantly than my home-brew approach at the time as well There’s an article on Adobe devnet that will get you started.
The Present – Adobe Consulting on Cairngorm Code Generation
Right now, I’d say that the amount of code that we would typically usefully generate hasn’t really justified the effort; code-generation is a decision that a technical architect will make on a project by project basis, but it certainly isn’t in our arsenal of practice-wide techniques that we apply to each and every project.
Peter Martin did make some attempts with the XDoclet 2 work that he did, building on some work by Joe Berkowitz of Allurent. As you can see from his blog entry, it was a lot of work to create value objects only, which in the grand scheme of our typical projects, don’t account for a whole host of development effort and time to maintain.
So in summary; right now we’re not employing a great-deal of code generation and don’t feel that we’re suffering in productivity because of it. Those coming from a Ruby on Rails background are often impressed at the ability to automagically generate so much scaffolding for CRUD type applications – I think the DAOFlex approach may work for you here, and remember we’re never necessarily advocating Cairngorm for your simpler Flex applications anyway. Someone asked me in blog comments recently whether Cairngorm and Flex could be more complex than Ruby on Rails with AJAX, and I guess sometimes it can be. However, those are two poles of a spectrum, and in-between there are a number of much-simpler non-Cairngorm Flex approaches that can be taken to rapidly deliver simple applications. There are times when i think you shouldn’t use Cairngorm.
I guess under the present tense, I would like tomention the work that has been done by Eric Feminella in a project he has called Cairngen. Eric’s motivation is to remove the repetition associated with creating Events to be registered with the Front Controller and their corresponding Command classes, by creating the notion of a "sequence" that can code generate stub classes for the Event and Command. Cairngen will also make it quicker for you to start a brand new Cairngorm Flex project, by creating all the project structure, folders and template classes for a skeleton Cairngorm project. Cairngen is a server-based solution, leveraging PHP and AMFPHP to manage the code generation from templates – it may work for your workflow, and is definitely worth checking out on Eric’s blog.
Though I’ve never used the product, I noted that WebOrb is now also generating Cairngorm code from templates as well, so that may be worth checking out if you’re using WebOrb already.
The Future – Integrating Cairngorm more tightly into Flex Builder workflow
I spoke in my last blog entry, that our Adobe Consulting team are constantly balancing client and project committments, with practice and community committments to deliver best-practices, guidance and productivity tools for those using the same tools and technologies that we do every day.
As we focus on Cairngorm 3, we’re also very focussed on enhancing the workflow for Flex developers who are working within FlexBuilder. We’ve a number of ideas that are more than simply push-button Code Generation that will yield the flexibilities and benefits that we consider from working with a Cairngorm architecture, and that will furthermore leverage the consistency and predictability of Cairngorm Flex development to assist developers in building applications with Cairngorm and Flex. That was a hell of a long sentence. It’s still very early days in our development, so we have nothing to preview or share at present … but hopefully that gives a little insight into where we’re going in terms of developer productivity around Cairngorm. I’m sure the consultants who have this work as their practice targets will release more information, or even previews, as and when they have something ready to share.
If I’ve missed any other code-generation or general Cairngorm productivity tools in my roundup, please feel free to add them here in the comments.
But hopefully that shares the current working practices within Adobe Consulting, and gives you some confidence in your own approaches.