From david at davidmintz.org  Tue Jun  2 11:36:40 2009
From: david at davidmintz.org (David Mintz)
Date: Tue, 2 Jun 2009 11:36:40 -0400
Subject: [zendframework] a modeling question
Message-ID: <721f1cc50906020836w1d32f7fdp64602e84197795fd@mail.gmail.com>

At
http://framework.zend.com/docs/quickstart/create-a-model-and-database-tableyou
see they use a DataMapper class to map the domain object to the
database. My question is, if you are totally certain that the back end you
will be using will be a database (indeed, a MySQL database) now and forever,
do you really need that extra layer?

-- 
David Mintz
http://davidmintz.org/

The subtle source is clear and bright
The tributary streams flow through the darkness
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/zendframework/attachments/20090602/e61bb4fa/attachment.html>

From mhernandez at techally.com  Tue Jun  2 11:46:21 2009
From: mhernandez at techally.com (Michael Hernandez)
Date: Tue, 2 Jun 2009 11:46:21 -0400
Subject: [zendframework] a modeling question
In-Reply-To: <721f1cc50906020836w1d32f7fdp64602e84197795fd@mail.gmail.com>
References: <721f1cc50906020836w1d32f7fdp64602e84197795fd@mail.gmail.com>
Message-ID: <1243957581.25060.149.camel@mikeh-ubuntu>

On Tue, 2009-06-02 at 11:36 -0400, David Mintz wrote:
> At
> http://framework.zend.com/docs/quickstart/create-a-model-and-database-table you see they use a DataMapper class to map the domain object to the database. My question is, if you are totally certain that the back end you will be using will be a database (indeed, a MySQL database) now and forever, do you really need that extra layer?
> 
> -- 
> David Mintz
> http://davidmintz.org/
> 
> The subtle source is clear and bright
> The tributary streams flow through the darkness

I found the extra layer to prove useful when I realized that my User
model needed to make use of multiple tables. I was able to update my
model to use multiple table objects when necessary. If you were going to
write all the SQL yourself instead of using the methods that
Zend_Db_Table provides, I guess it wouldn't matter as much?

--Mike H



From david at davidmintz.org  Tue Jun  2 12:09:28 2009
From: david at davidmintz.org (David Mintz)
Date: Tue, 2 Jun 2009 12:09:28 -0400
Subject: [zendframework] a modeling question
In-Reply-To: <1243957581.25060.149.camel@mikeh-ubuntu>
References: <721f1cc50906020836w1d32f7fdp64602e84197795fd@mail.gmail.com>
	<1243957581.25060.149.camel@mikeh-ubuntu>
Message-ID: <721f1cc50906020909waf728ebja675493d9d85939a@mail.gmail.com>

On Tue, Jun 2, 2009 at 11:46 AM, Michael Hernandez
<mhernandez at techally.com>wrote:

> On Tue, 2009-06-02 at 11:36 -0400, David Mintz wrote:
> > At
> >
> http://framework.zend.com/docs/quickstart/create-a-model-and-database-tableyou see they use a DataMapper class to map the domain object to the
> database. My question is, if you are totally certain that the back end you
> will be using will be a database (indeed, a MySQL database) now and forever,
> do you really need that extra layer?
> >
> > --
> > David Mintz
> > http://davidmintz.org/
> >
> > The subtle source is clear and bright
> > The tributary streams flow through the darkness
>
> I found the extra layer to prove useful when I realized that my User
> model needed to make use of multiple tables. I was able to update my
> model to use multiple table objects when necessary. If you were going to
> write all the SQL yourself instead of using the methods that
> Zend_Db_Table provides, I guess it wouldn't matter as much?
>
>
Well, I would ask, is it a crime to have some SQL in your model class --
again, assuming you're comfortable committing yourself to a db for
persistence? Also, we can make use of Zend_Db_Table's (and ..._Row)'s
higher-level methods (find(), save()) and keep the raw SQL to a minimim,
possibly zero.


-- 
David Mintz
http://davidmintz.org/

The subtle source is clear and bright
The tributary streams flow through the darkness
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/zendframework/attachments/20090602/12efccba/attachment.html>

From mhernandez at techally.com  Tue Jun  2 12:23:55 2009
From: mhernandez at techally.com (Michael Hernandez)
Date: Tue, 2 Jun 2009 12:23:55 -0400
Subject: [zendframework] a modeling question
In-Reply-To: <721f1cc50906020909waf728ebja675493d9d85939a@mail.gmail.com>
References: <721f1cc50906020836w1d32f7fdp64602e84197795fd@mail.gmail.com>
	<1243957581.25060.149.camel@mikeh-ubuntu>
	<721f1cc50906020909waf728ebja675493d9d85939a@mail.gmail.com>
Message-ID: <1243959835.25060.183.camel@mikeh-ubuntu>

On Tue, 2009-06-02 at 12:09 -0400, David Mintz wrote:
> 
> 
> On Tue, Jun 2, 2009 at 11:46 AM, Michael Hernandez
> <mhernandez at techally.com> wrote:
>         
>         On Tue, 2009-06-02 at 11:36 -0400, David Mintz wrote:
>         > At
>         >
>         http://framework.zend.com/docs/quickstart/create-a-model-and-database-table you see they use a DataMapper class to map the domain object to the database. My question is, if you are totally certain that the back end you will be using will be a database (indeed, a MySQL database) now and forever, do you really need that extra layer?
>         >
>         > --
>         > David Mintz
>         > http://davidmintz.org/
>         >
>         > The subtle source is clear and bright
>         > The tributary streams flow through the darkness
>         
>         
>         I found the extra layer to prove useful when I realized that
>         my User
>         model needed to make use of multiple tables. I was able to
>         update my
>         model to use multiple table objects when necessary. If you
>         were going to
>         write all the SQL yourself instead of using the methods that
>         Zend_Db_Table provides, I guess it wouldn't matter as much?
>         
> 
> Well, I would ask, is it a crime to have some SQL in your model class
> -- again, assuming you're comfortable committing yourself to a db for
> persistence? Also, we can make use of Zend_Db_Table's (and ..._Row)'s
> higher-level methods (find(), save()) and keep the raw SQL to a
> minimim, possibly zero.
> 
> 

I don't think it's a crime, but for me I think if I'm going to use the
framework, I'm going to try to use the framework's features wherever
possible, so I try to use Zend_Db_Table objects and so on, instead of
writing the SQL myself. Of course there are going to be times you need
to write your own SQL because not every case can be covered by the
framework, and luckily ZF makes it pretty easy for you in those cases.

For the most part though, even for joins, you can accomplish things via
the framework's built in classes or extend those classes.  If you begin
writing your own SQL for everything you might end up with an application
that is half ZF and half "DIY F" (the F is for framework, I swear). Now
that isn't necessarily a crime either, but one of the benefits of using
a framework at all is that it leaves easy maintenance possibilities for
anyone that is familiar with the framework you use, so if you end up
going off the deep end you might lose that benefit.

--Mike H



From tim_lists at o2group.com  Tue Jun  2 14:29:42 2009
From: tim_lists at o2group.com (Tim Lieberman)
Date: Tue, 2 Jun 2009 14:29:42 -0400
Subject: [zendframework] a modeling question
In-Reply-To: <721f1cc50906020909waf728ebja675493d9d85939a@mail.gmail.com>
References: <721f1cc50906020836w1d32f7fdp64602e84197795fd@mail.gmail.com>
	<1243957581.25060.149.camel@mikeh-ubuntu>
	<721f1cc50906020909waf728ebja675493d9d85939a@mail.gmail.com>
Message-ID: <381C0A67-4801-4523-9420-2C7F0C4D76D2@o2group.com>

> Well, I would ask, is it a crime to have some SQL in your model  
> class -- again, assuming you're comfortable committing yourself to a  
> db for persistence? Also, we can make use of Zend_Db_Table's  
> (and ..._Row)'s higher-level methods (find(), save()) and keep the  
> raw SQL to a minimim, possibly zero.

Absolutely not a crime.

Based on the quickstart example, you could essentially combine the  
model and mapper classes (essentially just move the mapper stuff into  
your model.

That would allow you to continue to leverage Zend_Db_Table, without  
littering your greater modelspace with mapper classes.

Or, you could dispense with Zend_Db_Table completely.  It's not  
terribly useful in a lot of cases.  I usually end up using it only for  
write operations, while any sort of reading is generally driven by  
plain old Zend_Db and Zend_Db_Select.

I would caution you that even if you're 100% sure persistence will  
always be a database, you might want to consider that the database  
platform might change, or you may all of a sudden become enamored with  
Doctrine or something.  So it does pay to keep things appropriate  
abstracted.

-Tim




From alan at alanseiden.com  Tue Jun  9 15:53:28 2009
From: alan at alanseiden.com (Alan Seiden)
Date: Tue, 09 Jun 2009 15:53:28 -0400
Subject: [zendframework] Zend Framework SIG Meetup, June 23
Message-ID: <4A2EBDB8.6070403@alanseiden.com>

Announcing June's NY-PHP SIG meetup for Zend Framework

When: Tuesday, June 23, 2009, 8PM, after the regular NY-PHP meeting
Where: TGI Friday's at 56th and Lexington, with "complimentary food and 
drink, thanks to Microsoft"

First, come to IBM (590 Madison Ave.) at 6:30pm to see Peter Laudati's 
presentation on Silverlight.

Afterward, join us at TGIF for the SIG meeting and discussion.
Bring your questions or tips about Zend Framework.

*** You must RSVP for the main meeting at IBM (nyphp.org) and we will
have the SIG at TGIF afterwards ***

Learn more here:
http://www.meetup.com/ZendFramework-NYCmetro/calendar/10499911/

Hope to see you there!

Alan
-- 
Alan Seiden
Zend Certified Engineer for Zend Framework
PHP i5 Solutions, Strategic Business Systems, Inc.
alan at alanseiden.com | 201-327-8746 x144 | blog: alanseiden.com



From alan at alanseiden.com  Fri Jun 19 16:38:56 2009
From: alan at alanseiden.com (Alan Seiden)
Date: Fri, 19 Jun 2009 16:38:56 -0400
Subject: [zendframework] Reminder: SIG Meetup, June 23
Message-ID: <4A3BF760.7020805@alanseiden.com>

Announcing June's NY-PHP SIG meetup for Zend Framework

When: Tuesday, June 23, 2009, 8PM, after the regular NY-PHP meeting
Where: TGI Friday's at 56th and Lexington, with "complimentary food and
drink, thanks to Microsoft"

First, come to IBM (590 Madison Ave.) at 6:30pm to see Peter Laudati's
presentation on Silverlight.

Afterward, join us at TGIF for the SIG meeting and discussion.
Bring your questions or tips about Zend Framework.

*** You must RSVP for the main meeting at IBM (nyphp.org) and we will
have the SIG at TGIF afterwards ***

Learn more here:
http://www.meetup.com/ZendFramework-NYCmetro/calendar/10499911/

Hope to see you there!

Alan
-- 
Alan Seiden
Zend Certified Engineer for Zend Framework
PHP i5 Solutions, Strategic Business Systems, Inc.
alan at alanseiden.com | 201-327-8746 x144 | blog: alanseiden.com


From alan at alanseiden.com  Mon Jun 22 14:15:29 2009
From: alan at alanseiden.com (Alan Seiden)
Date: Mon, 22 Jun 2009 14:15:29 -0400
Subject: [zendframework] Reminder: Tomorrow SIG Meetup, June 23
Message-ID: <4A3FCA41.1080109@alanseiden.com>

Reminder: Register by 3pm today (http://www.nyphp.org/rsvp.php)
for tomorrow's NY-PHP meeting and Zend Framework SIG meetup.

When: Tuesday, June 23, 2009, 8PM, after the regular NY-PHP meeting
Where: TGI Friday's at 56th and Lexington, with "complimentary food and
drink, thanks to Microsoft"

First, come to IBM (590 Madison Ave.) at 6:30pm to see Peter Laudati's
presentation on Silverlight.

Afterward, join us at TGIF for the SIG meeting and discussion.
Bring your questions or tips about Zend Framework.

*** You must RSVP for the main meeting at IBM (nyphp.org) and we will
have the SIG at TGIF afterwards ***

Learn more here:
http://www.meetup.com/ZendFramework-NYCmetro/calendar/10499911/

Hope to see you there!

Alan
-- 
Alan Seiden
Zend Certified Engineer for Zend Framework
PHP i5 Solutions, Strategic Business Systems, Inc.
alan at alanseiden.com | 201-327-8746 x144 | blog: alanseiden.com