The PHP Scalability Myth
Subject:   Java and PHP
Date:   2005-08-19 12:19:47
From:   cyberlife
Response to: Java and PHP

And can anybody give me firm examples as to why "mixing biz logic in the view can lead to all sorts of problems down the road."? We all "know" it's bad design, but why exactly?

It really all comes down to isolating changes. If something needs to be modified, how much of your program will you have to alter? I can give you a real-world example that I ran into with a colleague.

He had created a 50+ page application driven by a relational database on the back-end. The code for interacting with the database and processing query results was directly mixed in with the presentation logic. One day, he was asked to change the application's storage system from a relational database to Berkeley DB. He ended up having to nearly rewrite the entire system since his database code (and other related elements) was scattered around everywhere instead of being confined to one or two source-code files.

This scenario is common to many applications, both large and small. Small snippets of business code are used repeatedly in several places by presentation code. Any dependencies on how that business code actually does its job are going to spell trouble should you need to change things.

It's like going to McDonalds. Do you care about the details of how they actually prepare their burgers? Generally not -- you just care about the result. By not being dependent on their internal processes, they are free to change their ways without upsetting you. Same thing applies to programming ..... or any engineering for that matter.

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Java and PHP
    2007-07-25 14:57:20  Storm14k [View]

    I know this is older but I still see this argument with regards to php and I do not believe it has merit.

    Even prior to the advances made in php's OOP capabilities the file include flexibility of the language would allow you to achieve enough seperation to avoid this type of situation. The code and necessary html to represent a particular item could be written in one file and included where needed. Control variables could be used to handle differences between individual instances. And if the database connection was a problem DB::PEAR could have been used. To me it seems like most of the code/presentation/maintainability arguments against php stem from lack of a full understanding of the language and its capabilities.

    On another note I have yet to see what I would actually consider true separation of code and presentation as it is hyped by other languages when compared to php (mainly If you are putting anything in your html besides html then you are mixing code and presentation. It doesn't matter if its a php while loop, smarty template tag or an or jsp tag. They all do the same thing...loop over a piece of html and inject data values in place of place holders.