Did you notice that Jason says to use the TableDataGateway when the ActiveRecord won't cut it?
I am getting the impression that the Zend camp may have reservations about AR; But that's my own impression of course, but if that were the case, it's understandable.
Hmm, yes it does say so - but I find that his argument is way to generalizing, clearly the AR pattern can be used(altho I personally would prefer TDG over AR) with great success in complex web applications(RoR, CakePHP, etc.)Originally Posted by akrabat
I think a lot depends on how complicated you make your ActiveRecord. At the most simple leve, it represents a single row of a database table. At a more compilcated level, it can represent a single row of a database table and all other rows that are related to it.
The name of the Table Data Gateway discourages picking up all the relations to all the rows within the table.
Correct, mapping relations is not the TDGs job, as it's only ever responsible for one single table and shoult not care about the other tables in the db.Originally Posted by akrabat
Yes, thank you - someone (the person that wrote the article, don't know where you stand Selkirk ;p) who agrees with me. ORMs have thier place even in PHP - but I'd argue that all of them available are:Originally Posted by Selkirk
1. To slow.
2. To complex (ORM nature) for simple problems.
3. To simple for a rich domain model.
And as far as I can see, it's when you got a realy advanced rich domain model you start realy gaining something by using an ORM. And If you read the article that selkirk linked the author and many of the comments didn't even believe that an ORM is right in many RDM (Rich Domain Model) cases either.
I can see a possible argument related to performance hits, but the "less-than-optimal tight coupling to the data model" makes absolutely no sense to me. ORM's (especially ones like Hibernate) are an abstraction between the business logic of the application and the database. A good ORM should reduce coupling, if for no other reason than it forces the data mapping into one layer. I'm not saying that ORM's are required to do this (there are cleanly designed applications that do not use ORM's and still manage to encapsulate the data access in one spot) but they certainly make it easier. I can't imagine that anyone could compare an application using an ORM against one that has SQL queries spread throughout the entire code base and consider the latter to be less coupling than the former. Most PHP applications that I have seen (especially those written by developers who seem to think that MySQL is the only database that exists) are so tightly bound to the database it's not even funny. A good ORM can only help this situation, not make it worse.Originally Posted by Clemens Vasters
It seems to me that everyone is, just not in PHP. Hibernate is extremely common in the Java world. I'd wager that there are more Java web apps being written today that use Hibernate (or some other ORM) than those that do not. And RoR has made ORM very popular in the Ruby world. Of course ActiveRecord is not a full-fledged as Hibernate, but it's still an ORM.Originally Posted by Selkirk
No, I think it speaks to two things (as I've said in the past): (1) PHP the language/platform makes it difficult to implement a decent ORM and (2) most PHP developers lack CS backgrounds and tend to write more procedural than OOP code, and such developers would have a more difficult time understanding ORM's and why they may be helpful. My $0.02...PHP culture is very pragmatic. Perhaps the lack of good commonly used ORM in PHP is supporting evidence for this idea?
Oh, and one other thing:
My experience (although probably not as wide as his) is the exact opposite. I've found that those who advocate ORM's usually have a much stronger grasp of SQL and relational databases than those who are ignorant of ORM's. Most of the people I know who advocate/use them have done a lot of thinking about how to implement their own ORM, and mulling over that problem forces you to think a lot about data relationships and SQL syntax, etc. My experience may not be common, but there it is...Originally Posted by Clemens Vasters
Thing is tho, that this "higher" goal of decoupding the data model is often a pure dream. If you go around changing something in your db you're most likely going to changed your code also, as you have to change the mapping wich in turn effects the code. Yes in minor cases it's possible to adjust the mapping(say if you just rename a field, etc.) and it'll work anyways.Originally Posted by DerelictMan
Yes, and this is what I'm starting to argue for - decouple your datamodel and encapsulate your access without the overhead plus complexity of an orm. It's very well possible to do this.Originally Posted by DerelictMan
I'll never argue that this is good code, and I agree with you the amount of php apps I've seen with a html<>php<>sql .. god.. it's not even fun.Originally Posted by DerelictMan
It can actually complicate stuff even more, when it's not needed. If the developers had no idea of CS and good application design from the beginning, an ORM wont help.Originally Posted by DerelictMan
Well, the more then not hibernate statement is just grabbed out of thin air I presume. And in the Java / .NET world you have an application server, objects can sit around forever.. here we tear everything down when we're done(yes there are advantages to this approach also). When php get's an app server I can take your "but in the java world"-argument.Originally Posted by DerelictMan
To put it blunt: word. This is a big issue.Originally Posted by DerelictMan
I know this wasn't aimed at me directly. I understand and can see the benefits of an ORM - I just don't realy see it being the answer to everything as many people seem to think.Originally Posted by DerelictMan
I'd say lack of a good commonly used ORM in PHP is evidence that the development done in PHP is primarily procedural; ORM layers appeal most to what Fowler affectionately refers to as "object bigots", because if you use OOP extensively, you have no choice but to map sql data to objects.Originally Posted by Selkirk
Well I've done alot(I don't even dare to count the amount of hours I spent on this... ;p) of work on my orm, and how to work around different stuff - and many of my discoveries have led me to the conclussion that most of the times it's not needed(in php that is).Originally Posted by DerelictMan
Another thing that sprung to my mind about the current PHP ORMs is this: If you look at Hibernate, it's like the holy grail of O/R Mapping. It can basicly do anything you wan't and probably a few other things - and this is why it works. Hibernate is so packed with features that you can customize it to fit your exact needs.
This is also one of the big flaws with the PHP ORMs, and why they don't work for real(atleast no for me) - they just don't cut it feature wise. To be able to abstract an advanced database you need something like hibernate, that can do everything you wish and then some. EZPDO, Propel, Doctrine, ADOdb-AR, etc. won't cut it with advanced domain models as they're to simple. And for simple problems(simple domain model, or not domain model at all) they're to complex.
All code I do is OO, I'd never ever write something procedural. But just because you got OO code doesn't mean you have to abstract away your data layer into objects also.Originally Posted by 33degrees
People seem to have this wierd idea that nothing except objects in all cases will do, ever. I still wait for the day when I see:
$a = new Char('a');
$b = new Char('b');
$c = new Char('c');
$s = new CharSequence($a, $b, $c);
Also think if PHP had a tool to manage it all, ( I endlessly hear .NET people drowling over http://www.llblgen.com/ ) then ORMing in PHP would become popular.
Be interesting if the PHP/Eclipse thing manages to wire in some ORM tools too.
Yes, I agree that the data model itself is not likely to be completely decoupled. However, the particulars of the SQL schema can be. I've ran across a scenario (while maintaining legacy code) where an additional field was added to a table and a single-field primary key became a composite key. Not only was this a new piece of data to deal with, but it also affected the way the different tables were related...suddenly all of the joins in the SQL queries had to be altered. Making this change required touching dozens upon dozens of PHP files that took the most direct approach of simply executing a query and fetching results whenever they needed data. That is the nightmare scenario that I think ORM's can help you to avoid. In a similar case with an ORM, yes you'd have to update the mapping, and yes, you'd have a new getter/setter pair for the new field, but the only code that would have to be touched would be the code that required that new field. The particulars of the table relationships (i.e. constructing the joins) would be nicely isolated in the ORM layer.Originally Posted by thr
As stated, ORM isn't the only way to acheive this (as we agree on), but I still think it definitely encourages it if not enforces it.
Agreed. Some would argue that iBATIS acheives this goal. I haven't done much with it, but it does seem simpler to run with than Hibernate, and it still achieves the encapsulation of data access.Yes, and this is what I'm starting to argue for - decouple your datamodel and encapsulate your access without the overhead plus complexity of an orm. It's very well possible to do this.
TouchéIt can actually complicate stuff even more, when it's not needed. If the developers had no idea of CS and good application design from the beginning, an ORM wont help.
As in, do I have hard numbers to prove it? No, I don't. I'm just going off what I've observed. Nearly every single popular Java framework shouts from the rooftops how easy it is to integrate with Hibernate. An unbelievable amount of work has gone into the new EJB3 spec. Out of all the Java tutorials and available source code that I've seen, most all of it uses an ORM and not direct JDBC calls. As I said, it's just what I've observed. Have you observed something different?Well, the more then not hibernate statement is just grabbed out of thin air I presume.
Yes, that kind of supports my "the PHP platform makes implementing an ORM difficult" argument.And in the Java / .NET world you have an application server, objects can sit around forever.. here we tear everything down when we're done(yes there are advantages to this approach also).
No, that definitely was not aimed at you, or anyone else in this forum (and it wasn't really meant to be disparaging, anyway). I'm not arrogant enough to believe that anyone who doesn't advocate ORM's just doesn't "get it". There are definitely sound arguments against them, and I don't believe they are a silver-bullet. It's just that for the types of apps that I'm having to deal with I find them helpful.I know this wasn't aimed at me directly. I understand and can see the benefits of an ORM - I just don't realy see it being the answer to everything as many people seem to think.
*drools*Originally Posted by Ren
Yes, this can be done with an O/R M and other approaches also. I'd never, ever, argue that you should put raw sql in your code.Originally Posted by DerelictMan
AgreedOriginally Posted by DerelictMan
Yeah, I've been reading on iBATIS quite alot.. also I've been playing around with something i called "Signed ResultSets" - Just an idea I had and I'll post the results later some day.Originally Posted by DerelictMan
Originally Posted by DerelictMan
No, I haven't realy and you're probably right - but again the whole Java Env vs. PHP Env. kinda shoots down that this would be possible in php(I know you didn't say so - but I just wanted to say it ;p)Originally Posted by DerelictMan
Yeah it doesOriginally Posted by DerelictMan
I'll never doubt that ORMs have thier place, I'm mainly saying that today , in most of the php apps I see today an orm (and especially the current ones available for php) would just make things even more confusing then they already are. (untill we get a fast object database that is stable and fast for production use.. then I'll never, ever ever ever ever, look back )Originally Posted by DerelictMan
Obviously there is such a thing as too many objects. But if you're using a domain model, you're going to be mapping sql to objects, making some sort of ORM tool a neccesity. You may not agree with using objects to represent your data layer, but it is a very common (and I'd say rightly so) OO practice.Originally Posted by thr
I've never said I don't agree with it, I just said that for the majority of php applications today an ORM is not needed and will not ever be needed(especially as there are no nice ORMs for php currently, imho.)Originally Posted by 33degrees
I've been looking more and more on iBATIS sqlMaps, realy nice idea. Going to have a go at a small proof of concept port to php maybe, since I'm free all weekend to do what I want, yay! ;p
So this is your idea of a fun weekend, is it? May I suggest an alternative:Originally Posted by thr
Done to much of that, so not realy into it anymoreOriginally Posted by DerelictMan
At the moment, I have a sufficient iBatis implementation in PHP based on the iBatis.NET that is able to pass about 500+ assertions (similar to ones provided in .NET) including <statement>, <resultMap>, <parameterMap> and a little bit more. The missing pieces are dynamic SQL, distributed transactions, and long term caching techniques (php processes does not persist over requests).
The parsing of the .xml files are separated from the datamapper, thus allowing the mapper instances to be serialized and loaded later without parsing all the config files. I must say that, for the unit tests containing about 100+ queries over 11 .xml files, the serialized data was about 480kb.
with mapping,PHP Code:
$account = $sqlMap->queryForObject ('getAccount', $accountId);
HTML Code:<select id="getAccount" resultClass="Account"> select Account_Id as Id, Account_FirstName as FirstName, Account_LastName as LastName, Account_Email as EmailAddress from Accounts where Account_Id = #value# </select>
wie: interresting, I'm working on a small iBATIS sqlmap port myself now, but I think I'll change around some stuff to take advantage of the fact that php is dynamic and not staticly typed.