SitePoint Sponsor

User Tag List

Page 3 of 5 FirstFirst 12345 LastLast
Results 51 to 75 of 121
  1. #51
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    Basicly a Table Data Gateway is just that, a data gateway for your db tables. If you look at the Zend_Db_Table class you got a classic TDG example.
    Thanks. POEAA is right in front of me . Jason's book provides a chapter on it (15). Propel seems to implement it. Found a bit on MS Patterns & Practices as well.

  2. #52
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    Worcester
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Did you notice that Jason says to use the TableDataGateway when the ActiveRecord won't cut it?

  3. #53
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  4. #54
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by akrabat
    Did you notice that Jason says to use the TableDataGateway when the ActiveRecord won't cut it?
    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.)

  5. #55
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    Worcester
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  6. #56
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by akrabat
    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.

  7. #57
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I ran across this:

    The sirens are singing: O/R mapping

    If ORM were so great, everyone would already be doing it? PHP culture is very pragmatic. Perhaps the lack of good commonly used ORM in PHP is supporting evidence for this idea?

  8. #58
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    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:

    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.

  9. #59
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Clemens Vasters
    If an O/R mapper provides a nice programming or tooling experience, developers (and architects) are often willing to accept performance hits and a less-than-optimal tight coupling to the data model, because they are lured by the aesthetics of the abstraction.
    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.

    Quote Originally Posted by Selkirk
    If ORM were so great, everyone would already be doing it?
    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.

    PHP culture is very pragmatic. Perhaps the lack of good commonly used ORM in PHP is supporting evidence for this idea?
    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...

  10. #60
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh, and one other thing:

    Quote Originally Posted by Clemens Vasters
    And in closing: Many of the proponents of O/R mapping that I run into (and that is a generalization and I am not trying to offend anyone – just an observation) are folks who don't know SQL and RDBMS technology in any reasonable depth and/or often have no interest in doing so.
    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...

  11. #61
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    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.
    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.

    Quote Originally Posted by DerelictMan
    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.
    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.


    Quote Originally Posted by DerelictMan
    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.
    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.

    Quote Originally Posted by DerelictMan
    A good ORM can only help this situation, not make it worse.
    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.

    Quote Originally Posted by DerelictMan
    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.
    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.


    Quote Originally Posted by DerelictMan
    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
    To put it blunt: word. This is a big issue.

    Quote Originally Posted by DerelictMan
    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...
    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.

  12. #62
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    I ran across this:

    The sirens are singing: O/R mapping

    If ORM were so great, everyone would already be doing it? PHP culture is very pragmatic. Perhaps the lack of good commonly used ORM in PHP is supporting evidence for this idea?
    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.

  13. #63
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    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...
    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).

    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.

  14. #64
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    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.
    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.

    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:

    PHP Code:
    $a = new Char('a');
    $b = new Char('b');
    $c = new Char('c');
    $s = new CharSequence($a$b$c);
    $s->echo(); 

  15. #65
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  16. #66
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    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, 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.

    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.

    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.
    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.

    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.
    Touché

    Well, the more then not hibernate statement is just grabbed out of thin air I presume.
    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?

    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).
    Yes, that kind of supports my "the PHP platform makes implementing an ORM difficult" argument.

    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.
    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.

  17. #67
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    *drools*

  18. #68
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    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.
    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.

    Quote Originally Posted by DerelictMan
    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

    Quote Originally Posted by DerelictMan
    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.
    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.

    Quote Originally Posted by DerelictMan
    Touché


    Quote Originally Posted by DerelictMan
    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?
    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)

    Quote Originally Posted by DerelictMan
    Yes, that kind of supports my "the PHP platform makes implementing an ORM difficult" argument.
    Yeah it does

    Quote Originally Posted by DerelictMan
    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'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 )

  19. #69
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    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.

    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:

    PHP Code:
    $a = new Char('a');
    $b = new Char('b');
    $c = new Char('c');
    $s = new CharSequence($a$b$c);
    $s->echo(); 
    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.

  20. #70
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    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.
    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.)

  21. #71
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  22. #72
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    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:

  23. #73
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    So this is your idea of a fun weekend, is it? May I suggest an alternative:
    Done to much of that, so not realy into it anymore

  24. #74
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Australia
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

    sample usage
    PHP Code:
    $account $sqlMap->queryForObject ('getAccount'$accountId); 
    with mapping,
    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>

  25. #75
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •