Last year, I joined a developer team in a private project. The initial solution was a VB.NET web application, with class libraries projects, using the MereMortals Framework. The team had written many web pages, with simple use cases. The database was SQL Server 2008. It’s not a public project, so I cannot write about implementation details, but I can write down the global picture of the story.
There were many entities in the domain, and more were coming. So, for each new entity, a lot of new stuff should be written: the Mere Mortals framework classes, its validation classes, the data access, the DDL commands, stored procedures, web pages, etc. Then, I started to migrate the solution to code generation, using my open source engine AjGenesis. You can read an outcome of such experience in
That is what I call: “ajgenetizing” an application. Given a working solution, raise the abstraction level, discover the repetitive or similar code, the abstractions we need to model the system, the manual parts, and then, put all in a code generation process. The generated code should reflect a preexisting solution: it should be code you were proud of it.
The initial model was obtained from the database. As I wrote in other posts, this is not the ideal model source. But it was a pragmactic choice. I wrote:
After obtaining a working solution, we migrated the model to an abstract one: then, after some weeks using the database as the initial model, the database began to be generated from the new model, the direction of the process was reversed! Now, each new entity is described in the abstract model, and a lot of the rest text artifacts are generated by the code generation process.
This year, I migrated the templates to remove MereMortals framework, to use our own data access, one-to-many relations, with lazy loading, identity map, cache, validation, StructureMap as IoC, interfaces for abstractions, service layers, etc… The interesting part is that we could change an infrastructure solution to another, without much effort. The manual parts, and tests, were migrated to the new solution, but the model is still the same. And we are ready to migrate, if needed, to adopt an ORM framework, if we choose so. Or to adopt ASP.NET MVC2, or another solutions to different problems (persistence, validations, testing, presentation, etc…)
And, I’m sure the model could be used to generate the core of the application in another technology. This is not a requirement in this project. But it’s a kind of litmus test for our abstract model: if we need to change the database base, or the implementation language, all is in place to make the change.
Every week, we are discovering new entities in the domain. And we can add them easily to the abstract model: lot of technicalities (create tables, defining indexes, stored procedures, data access methods, relations in code, etc..) are then generated. The team can put its focus on domain logic and presentation details.
For me, it was a proof of the power of code generation from a model: it’s not only code generation. The key point is to have a model that help us to represent the solution we are building, to separate problems from tech solutions, and to have the options of change and improve things along the project.