NYCPHP Meetup

[Kenneth Downs]

David Mintz wrote:
> On Thu, 19 Oct 2006, Dell Sala wrote:
>
>   
>> The other possibility is to look into existing DataObject frameworks
>> that have already implemented the fancy stuff for you. I've used
>> PEAR's DB_DataObject. It's a bit of a pain to get up an running, but
>> it's solid. There are quite a few others -- here are a few:
>>
>> http://pear.php.net/package/DB_DataObject/
>> http://propel.phpdb.org/trac/
>> and CakePHP implements its own ActiveRecord  http://cakephp.org/
>>
>>     
>
> I was gonna say -- but didn't, for brevity's sake -- that I have spent
> several+ hours with Cake, and it does seem mighty cool, yet I've run into
> enough snags to wonder about the name. Like findAll() not fetching the
> data that I need and having to write custom SQL anyway.
>   
I'm at pains to ask at this point if we should question some of the 
basic assumptions of the MVC model.

Underneath MVC is usually an ORM philosophy, whether it is stated or 
implied.  The ORM philosophy tries to cast tables into OO terms, and 
IMHO this is why the approach tends to produce at least as much work as 
it eliminates.

In fact, the data tables are fully encapsulated by the database server 
and do not need to be encapsulated further into classes.  Doing so 
introduces obfuscations which then must be un-obfuscated, so author ends 
up doing work to do accomplish an unnecessary goal, which then requires 
further work to undo. 

By contrast, a generalized query-by-form is far easier to write by 
approaching it as a simple function that need only know a table name, 
and the column types and widths.  It does the same thing for every table 
otherwise.  You can put it into a class if you like, but it works just 
as well as a library routine.

As an example of this, check out one of the apps we will be demoing at 
Tuesday's Andromeda presentation:

http://dhost2.secdat.com/demo_peds

Username and password are both "guest".

Look at the menu on the left, skip the first two entries 
"ProcedureDiagnosis X Ref" and "Claims" and look at the next few 
entries, "Procedure Codes", "Prodedure Groups" and so forth.  Each of 
these tables is pure zero-code, not even a three-line class declaration 
went into any of them.

Other more interesting tables are much lower on the menu, particularly 
"Carriers", which contains real data, and "Families".  We're loading 
fake data to the "Families" and "Family Members" also.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20061023/f00f229f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20061023/f00f229f/attachment.vcf>