NYCPHP Meetup

[Hans Zaunere]

Robert Redcay wrote:

> Hi all,
> I apologise if these questions are too broad in scope, but I'm working 
> on redesigning a medium-sized e-commerce web application written in PHP 
> with a Postgres database. I've already decided on the frame work 
> (MVC-type model based on the Phrame project using smarty for the view, 
> objects for my business model and a php file as the controller), but 
> there are a lot of other pieces I'm still considering and the same 
> question keeps coming up.. "Is this just overkill or will it help with 
> maintainability, reusability, etc.?"

In my opinion... yes  :)

> Some of these questions are as follows:
> 1. I'll be using Pear's DB abstraction layer, but am still wondering 
> about a database class to encapsulate my sql, querying the db, and data 
> retrieval.  I've seen libraries (like DB_DataObject) which create a 
> class for each table (with that table's columns as its class attributes) 
> that extend a base class which has functionality for building sql for 
> simple selects updates and deletes. I like this idea, but it seems to 
> get pretty squarely when it comes to joins and more complex queries. I'm 
> wondering if any of you have had a good experience with DB_DataObject or 
> similar libraries. My alternative is to have hard-coded sql and database 
> calls within each script, which seems like a poor choice.

I've never used DB_DataObject itself, but have played at writting similar structures on my own, and have seen code based heavily on this type of model.  For one, there's a great deal of overhead involved for all this abstraction.  Secondly, as you mention, things begin to fall apart with complex queries, joins, etc. and you will end up making many hacks to get things to work.  Thus, there's a good chance you'll end up with hackish code, that's slow.  If you're using PostgreSQL, take advantage of one of the better ideas in abstraction modeling since a bread slicing machine; stored procedures and views.

> 2. I've also seen "form" classes to handle form elements and data 
> validation for all html forms (think oohforms, and others). This is a 
> little bit more difficult to implement when using Smarty templates, but 
> still possible. However, with only about 10-20 forms on the entire site, 
> it seems like it's potential overkill. Does the group have any opinions 
> about the best way to handle forms?

Abstraction with forms, and input from browsers in general, can be a good thing, although again being careful not to go too far.  For larger projects I use a "unified request processor" which is a single page, or set of included pages, that validates and aggregates input before handing it off to the real logic of the application.  As for rendering the form's HTML itself, PHP is a templating engine :)

> 3. Lastly is a question that's specific to my frame work (the MVC 
> model). The Phrame project includes a huge array used to map the user's 
> request to an action. Although this provides a loose coupling between 
> requests and actions, which would be good for extensibility, it seems 
> like a pain to have to build and maintain this array. Alternatively, I 
> could just assume a 1-to-1 relationship between requests and actions. Do 
> any PHP/MVC gurus have an opinion about this?

Of all the places for abstraction, I've had the best luck adding it to "where the rubber meets the road."  Once you can easily manage the requests that come in, and either reject or cleanse them, your business logic becomes much simpler and abstracted, since there's isn't the need for pedantic validation, security, etc.

http://phrame.sourceforge.net/docs/guide/controller.php is maybe a little heavier than I've done a similer model, but fairly close IMHO.

> Also, if anyone has any general tips for designing profesional-grade web 
> applications that they'd like to share, please do so.

All I can say is there's never a free lunch.  Abstracting things out tremendously may initially appear to reduce work and increase flexibility, but in the end there will always be workarounds needed.  And, if thing's are too far out, you'll end up with more pain than gain.  Somewhere in the code, the actual work has to happen and I haven't found that wrapping it in an onion of abstraction layers is that beneficial.

H