NYCPHP Meetup

[Jon Baer]

The key you are missing is the idea of a "hasMany", "hasOne",  
"hasAndBelongsToMany", "belongsTo", and the other conventions.

With that many of the joins are automagically created for you and you  
generally dont need to worry about your bindings are they will happen  
unless you tell them not to.

I think its about more to using ActiveRecord than just that record  
itself, its about how the row is encapsulating other logic which  
saves you time and work from figuring out.

I just browsed through the CI docs @ http://www.codeigniter.com/ 
user_guide/database/active_record.html and (no offense) have to say  
that I really can't see what you get out of it, even the chaining  
part ...

$this->db->select('title')->from('mytable')->where('id', $id)->limit 
(10, 20);

(ehh looks like straight SQL to me ;-)

So it looks like you would have to join and do all the work vs. say  
Cake where you would stick w/ a convention and have it all wrapped up  
for you.

(BTW, anyone correct me if Im wrong since I too am trying to explore  
what the pros/cons of other frameworks are).

- Jon

On May 11, 2007, at 1:56 PM, Joseph Crawford wrote:

> Guys,
>
> We are using CodeIgniter for our framework that will run our sites,
> however the database implementation that they offer is based on the
> Active Record pattern.  I have been running into issues that are
> making me think this is not the pattern for us to use.
>
> I have been going through the php|arch guide to php design patterns
> and I believe that we would be better off with the Data Mapper
> Pattern.
>
> All of these patterns bring up a concern with me though.  They are
> stating that each class should be related to one table.  We have
> things setup like this.
>
> Tables
> Content
> JobPostings
> Articles
> Reviews
>
> etc.  Each of the tables have an entry in the Content table since they
> all share Content in common.  Currently we have the Active Record
> pattern and our models extend a base Content model.
>
> So for example our job postings would be like this
>
> http://jobs.ere.net/job/3431/
>
> It will call the JobPostings model with the $this->jobs->load(3431);
> which will load the job info, which then in turn calls
> parent:load(3431); which will load the content for that particular
> job.  I could do this in one join query and there are other times
> where it would make more sense such as when grabbing multiple
> locations for a JobPosting, etc.
>
> My question is how can you join tables and still stick to the patterns
> that I am reading about?  Does joining tables completely bypass the
> reason for using these patterns?
>
> I am not asking how to do a join, i know how to do that ;)  I just
> would like some insight on the best practice when it comes to using
> these patterns.
>
> Any insight would be greatly appreciated.
>
> -- 
> Joseph Crawford Jr.
> Zend Certified Engineer
> Codebowl Solutions, Inc.
> http://www.codebowl.com/
> Blog: http://www.josephcrawford.com/
> 1-802-671-2021
> codebowl at gmail.com
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php