Friday, November 09, 2007 2:25 PM
This project exists to fill what we perceive to be a few voids in the ORM & code-generation scene. First, there seems to be unnecessarily strong correlation between the power of generated code & the complexity of the generator or framework that produced it. Second, there seems to be a general lack of appreciation for the power available within the relational back-end; while datastore independence is a laudable goal, most enterprise applications' choice of datastore is rarely subject to change. Third, in the "generation vs. framework" debate, we take a decidedly puruist stance on the "generator" position, believing that generated code should never introduce new dependencies into a project. Finally, we feel that all of the above should and can be achieved with extreme attention to delivering optimum speed, performance and scalability in the generated code.
StormFactory takes a stored-procedure oriented approach to object relational mapping. This frees front-end developers from caring about the relational details of the database, which is exactly what an ORM tool is supposed to do for them. This puts the DB engineer in charge of de-normalizing the data into a sensible topography right at the database level, in stored procedures. Developers should then be able to manipulate and save those abstracted entities, individually or in sets, without concern for the underlying table relationships. StormFactory facilitates exactly this pattern of development.
The most generalized use-case description for StormFactory goes something like this... Just point StormFactory at a database, pick one of the SELECT procedures, set a few options and watch it go... it will generate an entity representing the procedure's rowset, a data-access class encapsulating a generic collection of the entity, and a SAVE procedure that handles both inserts and updates (or both simultaneously!) of an individual entity instance or a whole set of them. The entity-specific data-access class will also perform a number of other useful tasks, like filtering a cached collection based on any combination of field values, formatting non-string fields as strings when desired, keeping track of state, and serializing and deserializing the entity/set to or from XML for SOA or persistence purposes.
A few of our most important guidelines for the project are:
1. Generated code will have no external library dependencies of any kind
2. To keep the memory footprint small, Entity classes reference only intrinsic System types
3. For speed and footprint reasons, data transactions will all be carried out using DataReaders;
no heavyweight objects (e.g. DataSets, DataAdapters, DataTables and XmlDocuments) will
appear in generated code
4. Relational databases excel at set-based operations, so developers should not have to loop through collection classes to perform data chores at runtime. StormFactory uses SQLXML to make passing collections of entities around as easy as passing an individual instance is under other design philosophies.
5. There will be no template languages to learn; C# developers presumably already know C#, so that will be the language of the generator itself
6. To make code-maintenance easy, generated objects will be produced as partial classes; this lets developers add all the custom code they want to their objects using separate files, eliminating worry about losing work the next time they regenerate the objects.
Though we may extend the project into a more language-independent design in the future (Mono, Java), at the present time StormFactory is specific to C# and Microsoft SQL Server 2000 or 2005.