Re: Re: Separating business logic from data store logi

Hello, On 11/04/2003 12:03 PM, Arthur Hundiak wrote:

Mr Lemos, Thank you for your comments. I probably should have made clear that my original email was directed to the PEAR group. I know there are a number of code generating enviroments out there. And Metastorage certainly appears to be quite impressive. But I feel it to be somewhat overkill for my modest applications.

Sorry, I was not telling you to use Metastorage. I was just point an example of a code generation based tool that generates code without the inconviniens that I pointed in your approach. I do not want to stop you from using your approach unless you decide that is good for you. I am just sharing my points of view and experience to tell why a code generation based solution can result in code that may have a smaller memory footprint and execute faster. I usually do not mention this much because it may seem that I am seeking to obtain an undue credit, but let me tell you a short story. A long time ago (almost 4 years ago) it was created a mailing list to discuss what should be a standard template engine for PHP. Many discussions were hold and since I had previous experience in developing templating systems based on code generation, I decided to post this message to share my ideas on how a code generation could be so much faster and efficient: http://news.php.net/article.php?group=php.template&article=186 11 months after that Andrei Zmievski announces Smarty 1.0 based on an approach that is practically what I previously described. http://news.php.net/article.php?group=php.template&article=531 What I mean with this story is certainly not: "Hey, I am great, I proposed what Smarty is!". What I mean is that I am sharing long time experience regarding tested code generation based solutions because I know how much more efficient they can be. I am perfectly aware that code generation solutions may not be perfect so solve all problems and so I am willing to discuss the pros and cons of each aspect.

The comment about "very fat base classes" is confusing. The application I described is real and had been in production for two seasons. The BO_Item class has 70 lines of code. The BO_Items collection class requires 100 lines while the SQL BO_ItemPersist class has about 250 lines. Standards vary but I would not term these classes as being "fat". No doubt my explanation of these classes was unclear.

Sorry, I was not clear to why your approach is based on fat base classes. What I mean is that your data objects base classes certainly have functions and variables that do things that you may or many not need in your applications precisely because they are generic. They are not aware of application specific needs that could make them do without all those variables that are necessary. The problem with this is mostly because in your applications you will probably create many objects, possibly tens or more, in each script. All that code and variables in the base classes will not be necessary. So, they are like fat because they waste memory and slow down object creation. If you multiply that fat by as many times your data objects will be created to run a single script, you can see why it is really important to work with slim classes, hopefully not subclasses of something. Since the code generation approach followed by Metastorage is based on a data model that the developer specifies, Metastorage can do the necessary optimizations to discard all variables and functions that would not be needed by the application. See what I mean?

-----Original Message----- From: Manuel Lemos [mailto:mlemos@acm.org] Sent: Monday, November 03, 2003 3:20 PM To: pear-dev@lists.php.net Subject: [PEAR-DEV] Re: Separating business logic from data store logic Hello, On 11/03/2003 06:21 PM, Arthur Hundiak wrote:

===================================================== To Summarize, here are the classes I think we need to make an application less dependent on data store details: BO_Item - Represent one business object such as a game or team. BO_Items - Represents a collection of business objects BO_ItemIter - Helper class used to cycle through items in a collection. Includes custom sorting and filtering capability. BO_ItemPersist - Data store specific information about a given BO_Item object. It's basically an interface which allows persisting and

retrieving

BO_Item objects from/to different data stores. It can also be used by admin classes to do things like table creation.

If you care for an opinion, the problem is this approach is that it leads to very fat base classes that bundle all possible functionality that your application may or may not need. This leads to bloated applications that take more time and memory to load. A better approach is to have a code generation engine that will only generates what your data object classes need. The way to do it is follow a Model Driven Architecture (buzzword of the moment MDA) where the generator engine generates data object classes that do not inherit any code from any fat base classes because they already have only the code they need. There would be a lot more to say about this, but to sum it up, this is is the approach followed by Metastorage. You just design your data model in a simple XML file, that includes classes with variables, relationships and validation rules, as well the definition of functions that perform standard operations to manipulate the objects. Then Metastorage generates all the code for your classes. It will not generate code that may not be necessary. For instance, if you do not need a function to delete objects from storage, it will not generate such function. It just generates the functions you specify based on your own knowlegde of what you need. If later you need more or less, just change your data model definition and ask Metastorage to regenerate the code for you. It just takes few seconds, despite the compiler is fully written in PHP. Additionally, Metastorage may also generate classes to handle Web based forms to perform standard user interface operations on your class objects. The user interface presentation is defined by theme based template definitions. Templates do not contain absolutely no code, just place holders, so you can produce the templates in any HTML designer program. But to avoid you to waste time on producing new templates just to test your projects, Metastorage comes with pre-built themes that make your applications look very much like desktop applications of well known operating systems. Take a look: http://www.meta-language.net/screenshots.html Conceptually your model, business and user interface logic are all separate, but since Metastorage makes it easy to rebuild optimal code for what you need in a few seconds, the generate code is tightly couple for greater efficiency. If you want to know more about Metastorage, just go in here: http://www.meta-language.net/metastorage.html There is a tutorial to get beginners quickly started that is still under productions but a copy of the current version can be obtained here: http://groups.yahoo.com/group/metal-dev/files/metastorage/tutorial.html

-- Regards, Manuel Lemos Free ready to use OOP components written in PHP http://www.phpclasses.org/