Murray @ PlanetThoughtful wrote: > Once he understands how to solve class abstraction problems such as > the one he is asking about, he will be better equipped to deal with a > wider range of application development tasks. I agree with this. > 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. I think the whole DAO/ORM approach is something that most programmers who are fans of OO stumble into as part of their natural development. I know that in my earlier projects I had implemented some type of this pattern without fully realizing that I had done so. It's just natural to consider at some point that you should represent entities in your database as objects (if you're an OO proponent). In one of my earlier PHP projects, I implemented a very basic ORM that represented only single entities and didn't quite handle multiple entities very well, or the relationships between entities (this seems to be where Chris is currently). Then for the next project I added better support for multiple entities and relationships, but it was a half implementation, because I didn't represent the related entities as full objects (for example, if a Customer has a list of phone numbers, I had the Customer object return them as an array of strings rather than an array of PhoneNumber objects). I also had no support for recursion when saving or updated objects (for example, in Propel, you can create a new Customer object, create 5 new PhoneNumber objects, attach them to the customer, then call the save() method on the Customer and it will recurse through all attached objects, saving each of them). 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. My point is, I had implemented my own home grown ORM about 3-4 times, and while each one was much better than the one that preceded it, I still wasn't quite all the way towards a 100% general implementation. That's when I found Propel. It got so many things right that I hadn't figured out how to solve, as well as implementing things that I hadn't even considered yet. Now, you could argue that going through all those iterations and refactoring my own ORM helped me to improve my skills as a programmer, and you would be right. That's where I agree with you, somewhat. :) However, I was many many iterations away from improving my ORM to the point where it would be as useful as Propel (and that's assuming it would ever be that useful). The guys who developed it (and I'm sure the same goes for Manuel and Metastorage) concentrated on making the best general purpose ORM they could make. IOW their whole goal was to build an ORM, while my goal each time was to develop one for the purposes of finishing whatever real project I happened to be working on. That meant they were closer to the problem, had more experience with it, and were willing to do more to solve it more fully and generally than I was. Originally I intended only to look at the code they had created and learn from it, using their ideas in my project. I started that way for a few days, but I realized that there was so much they had accounted for that I didn't even think of that it would be better to simply use their tool rather than trying to reinvent it. 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. I also think that it helps developers (as it did me) to periodically investigate how others solve problems...not just by asking questions in forums and getting pointers/gentle knudges, but by actually perusing code for working projects that others have created. It helps bring some fresh ideas and perspectives into your work, and prevents the whole development "inbreeding" by injecting some fresh DNA into the pool. :) Often we as individuals can't see the forest for the trees, so I think looking at someone else's solution can help you to step back and view the full picture that you might have been missing. 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". :) Sorry, I didn't mean to ramble on that long... :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
