Re: Re: Suggestions for class design

From: Date: Thu, 22 Sep 2005 04:48:44 +0000
Subject: Re: Re: Suggestions for class design
References: 1 2  Groups: php.general 
Request: Send a blank email to php-general+get-222967@lists.php.net to get a copy of this message
Hello, on 09/20/2005 10:04 AM Michael Sims said the following:
This is not to trivialize your Metastorage project (or, to be more accurate, I know nothing about it, so it's not my place to trivialize it or otherwise), but to point out that 'out-of-the-box' solutions to fundamental coding development problems probably ultimately makes for a poorer programmer. I could well be wrong, but it seems this is a case of "give a man a fish" as opposed to "teach a man to fish".
I see your point, but I'm not so sure I agree fully. Manuel suggested Metastorage (which makes sense, it's his project and he's most familiar/comfortable with it), I suggested Propel because that is what I've used. I think we both suggested existing ORM's for the same reason... namely that properly implementing a full featured ORM is an extremely difficult thing to get right. I don't know anything about Chris's skill as a programmer, but he's bound to reinvent the wheel several times over, and poorly to boot. I believe that implementing an ORM is one of those things that you cannot fully understand and appreciate until you've tried to do it and failed. IMHO it's only after you've built one that you realize what you really need, and by then it needs to be rebuilt. It's kind of like Fred Brook's "plan to throw one away; you will, anyhow", or at least it was for me.
Right, I could not have said it better, especially the part about people that prefer to break their heads trying to do something that others have done, providing much more mature solutions. I am including myself in that group of people. 3 years ago I started developing Metastorage but only after have looked at several solutions and learned they had too many deficiencies to be adopted. That study helped me realizing what would be the important design mistakes to avoid.
Another thing I had done halfway was support for querying objects (without using SQL). Basically I had created different types of criteria that could be used, but my support for criteria wasn't general enough. IOW, if I didn't forsee that you would want a particular type of criteria, then you couldn't use it. Propel gets this right by supporting any arbitrary criteria using their Criteria object approach (and I'm sure Metastorage has similiar functionality). If you can represent it using SQL, you can represent it using Propel's Criteria.
Metastorage provides its own OQL (Object Query Language). This means that you can define functions for your ORM to query objects and associate a search expression using that OQL. Metastorage compiles that expression into SQL at code generation time, that may include parameters to be passed to the function at run time. This way the code generated by Metastorage does not waste time or memory building the SQL search clause at runtime, because all query decisions are antecipated at run time. This results in fast code that is very compact.
I think it's important to point out, however, that I have learned just as much from using Propel as I did from creating my own ORM....I didn't just simply drop Propel into place and run with it. First of all, I modified it a good bit to work better for my environment. Secondly, as a general rule I don't incorporate any third-party code/libraries into my codebase without at least doing a cursory review through the code. Since I was particularly interested in how this problem was solved, I investigated it more thorougly than I normally would.
Right. I feel that I need to clarify that Metastorage approach seems to be very different from Propel. Metastorage generates self-contained code. This means that it generates code that does not depend on extra libraries to perform its function, which is ORM. Of course it uses Metabase to access the database but Metabase does not implement the base ORM functionality. Other than that, Metastorage generated code does not depend on anything else.
Now, with all that said, it's possible that Chris isn't to the point where he would benefit much from plugging in another ORM...in order to learn from someone else code you at least have to have a basic understanding of the problem they are trying to solve, or it will all be greek to you. And if that's the case then you're right, it might hurt more than it will help. So let me amend my recommendation by saying "check out Propel/Metastorage if you're willing to actually study the approach it takes as opposed to simply plugging it in". :)
Right, regardless of what Chris decide, my suggestion was not to use Metastorage but rather take a look first to what generates. Metastorage generated code even comes with comments so it easier to understand what it does and why. -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html

« previous php.general (#222967) next »