NYCPHP Meetup

[Dell Sala]

Kenneth Downs wrote:

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

To be honest, I've really just fallen into an MVC approach as I've  
learned, so I can't really compare it to anything other than the  
chaotic php/sql/html I used to write when I got started. I suppose I  
agree that ORM and MVC may not save time in the short-term, but I've  
found it can have a huge impact on the maintainability of my code. It  
does not mean I write less code -- it just gives me structured  
buckets to put it in. I also find the code becomes very expressive  
with MVC and ORM. I can glance at it 6 months later and know exactly  
what I was trying to do.


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

This is interesting. I've thought about this before, but haven't  
heard anyone else express it. But a table is just data, no? I've  
found it useful to wrap tables in classes so that I can attach  
business logic to them.


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

I can't quite visualize it. I'm looking forward to seeing some  
examples at your presentation this evening. I'm always look for a  
better way...

-- Dell