Hello, on 02/07/2008 02:18 AM Nathan Nobbe said the following: > well i think its worth a mention that qcodo has an article that > distinguishes > 'ActiveRecord classes' from the 'ActiveRecord pattern'. > http://www.qcodo.com/documentation/article.php/6 > what it mainly says is that code generation increases performance over > runtime > analysis of some model; eg. the database schema or perhaps some other > representation, such as xml (or yaml [apparently ;)]). the article also > classifies > ruby on rails as one of these obfusticators of fowlers original pattern; > greg, thoughts ? Yes, 6 years ago I analyzed the approaches of many these solutions that analyze database schemas at run-time and cache the results . I concluded that is not by far as efficient as a full code generation based solution. A code generation based solution will generate code that does what is necessary without any additional run-time libraries. Those caching solutions still need to read cached information and interpret what is cached. Not only they spend more time but also more memory, especially if you need to load a pile of classes to load your caching engine and run-time interpreter. Another problem I found in those solutions is that often you need to inherit from a fat base class that implements all sorts of functionality that you may need at run-time to perform object-relational mapping operations, even if your application objects do not need all that functionality. I concluded that it would be more efficient to generate root classes that just include the functionality you have. For instance, if you do not need to delete objects from you application, there is no sense in having that functionality in your objects. The results is persistent classes that do not inherit from fat base classes and are much thiner and faster to load and execute. Yet another problem of the solutions that defer mapping to runtime libraries is the composition of queries with conditions that need to be composed at run time. I concluded that is much more efficient to have an object query language (OQL) that lets you define the conditions of your queries. These queries are processed at compile time and the compiler generates efficient SQL code that does not need to be composed at run time. Your applications just call a single function to execute object queries that satisfy the conditions that you defined. This results again is much thiner and faster code that does *Just Exactly What You Need* (_JEWYN_). All these details that I mentioned have been implemented by Metastorage, which is an ORM code generation tool. http://www.metastorage.net/ The generated code is very satisfying because it looks exactly like what I would write if I had to do it manually, except that I did not have to spend a lot time writing it. I just defined my business objects a simple model file that describes the classes, relationships, validation rules, and functions I need to manipulate those objects. The compile time is measured in a few seconds. The time this tool took to develop is paying more and more on every application feature I need to implement but I do not need to waste hours or days coding the persistent object classes. There are more details about the Metastorage approaches to each problem on the FAQ if you are interested: http://www.meta-language.net/metastorage-faq.html -- Regards, Manuel Lemos PHP professionals looking for PHP jobs http://www.phpclasses.org/professionals/ PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
