SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 28 of 28
  1. #26
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,194
    Mentioned
    17 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by oikram
    Oddz do you still use a DAO per table or you have a generic DAO?
    No – I have been using a ActiveRecord based system.

    PHP Code:
    $user = new User(
        array(
            
    'username'=>'isausername'
            
    ,'password'=>'isapassword'
            
    ,'email'=>'sa@email.com'
            
    ,'profile'=>new Profile(
                array(
                    
    'firstname'=>'isafirstname'
                    
    ,'lastname'=>'isalastname'
                    
    ,'page'=>'isaage'
                
    )
            )
        )
    );
    $user->save(); 
    PHP Code:
    $user User::find(
        
    'one'
        
    ,array(
            
    'include'=>'profile'
            
    ,'username'=>'isausername'
        
    )
    );
    $user['profile']['lastname']; 
    You can catch a glimpse of the evolving library here if you like.

    It all works on a generic level once the tables have been defined in terms of relationships, fields, etc.

  2. #27
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I will stay with DAO I guess, at least for now. At least for this project. At least for sometime. Otherwise, I will end up on developing absolutely nothing. However, I find myself in a position where I need to deal either with one general DAO or one DAO per table, where the last one, on my opinion, is pretty much organized and simple for my newbility. But if your experience on several DAOs have been catastrophic or something, I'd like to hear before I walk on the same road.

    Regards,
    Márcio

  3. #28
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,194
    Mentioned
    17 Post(s)
    Tagged
    4 Thread(s)
    Well if something has been working for you I wouldn't recommend changing it.

    I developed my own to eliminate code repetition and database changes in a agile development environment. Also, to support calculated columns, aggregates, subqueries and elimination of repeating results when two or more tables are joined together in anything other than a 1:1 relationship.

    Just for example I recently added a field to one of my apps tables. It then took only one line of code in my model for that table for the entire application to support it. However, if the queries where hard coded in a DAO structure I would need to go through each DAO and write in that column – no thanks.

    The other thing that I always find teeth pulling is support for aggregates and calculated columns. Something that was written into the library from the very beginning were most libraries would require some form of lazy loading or self defined methods to achieve the same thing. For instance finding all users and their number of blogs. Easily supported with the following syntax that issues one query.

    PHP Code:
    $users User::find(
        array(
            
    'dynamic'=>array(
                
    'num_blogs'=>'count(*)'
            
    )
            ,
    'include'=>'blogs'
            
    ,'group'=>'id'
        
    )
        ,array(
            
    'require'=>false
        
    )
    );
    echo 
    $users[2]['num_blogs']; 
    However, those are/were my specific needs and wants for managing database info on the domain side of things. If the DAO is working well for you then you shouldn't change it. Especially if you have developed a large portion of the app using that methodology.


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
  •