Application Generation: Orchestrating the Process
Of course, you need a “generate” method so you can ApplicationService.generate(MyApplication,”application”), passing an application IBO into the generator. But I really don’t think that applications should know how to generate themselves, so we need to compose the ApplicationService with a Generator.cfc which I’m going to put into a subdirectory in my library (.com.lib.generate) so when I add other generation focused cfc’s I have the option of putting them in the same directory and using the package (Java: protected) scope, treating generator.cfc as a facade to the entire generation process.
Initially I’m just going to give Generator a single public generate(Object,ObjectName) method which orchestrates the generation process for a given application as I want to keep it as shy as possible. I can always open up the interface a little later if I need to.
The generate() method is a strategy pattern using the ObjectName to call generate#ObjectName#() if it exists. Usually this would seem like unreasonable indirection, but I am not sure of the relationship between generators and methods (maybe one method will generate all object types – maybe only some object types will be generatable – maybe groups of types of objects will share a single generate method) so I’m going to encapsulate that potential variability upfront and then see where things go from there.
So, how should the application generator work? I’m looking to just orchestrate a bunch of discrete calls for provisioning directories, static files, CF templates, DSNs and IIS sites and for generating methods, classes and other scripts. I’m going to start by putting together a lot of little cohesive components for handling each of these issues (hey they’re singletons – how much does it really cost?!) and once I’ve got the interfaces down and each component working in a test harness, I’m going to have to write just a little bit of ORM goodness (a getAssociated() base IBO method) to get all of the directories and fields and methods and classes that relate to a given application to efficiently generate everything with a single lazy initialized “Application” object.
Why don't you think an application should know how to generate itself? I am interested to hear drawbacks of that approach because it is my MO.
However, cohesion is often a matter of preference, previous experience and currently popular approaches in your language(s) of choice, so I wouldn't disagree with putting the generation code within ApplicationService, it just wouldn't be my personal preference.
Sometimes there are business reasons for the choice. If you are working for hire but using your own properietary generator, you may use an external generator so clients have to pay every time they want you to regenrate functionality. If you don't generate too many applications, I would definitely recommend including yur generator as part of your code otherwise you'll end up with generators and applications that are out of synch and it becomes a mess. If you are committed to a true software product line approach, there is nothing wrong with having an external generator (and regenerating all of your apps automatically every time you upgrade it), but there is also a place for inline generation.
I don't think there is a "right" answer and I think as people move towards generating applications most people will use a combination of the two approaches.