{"id":1507,"date":"2018-01-19T19:22:55","date_gmt":"2018-01-19T19:22:55","guid":{"rendered":"http:\/\/goofy-trucks.flywheelsites.com\/smart-architectures-in-php-page-2\/"},"modified":"2018-01-19T19:24:50","modified_gmt":"2018-01-19T19:24:50","slug":"smart-architectures-in-php-page-2","status":"publish","type":"post","link":"https:\/\/phpbuilder.com\/smart-architectures-in-php-page-2\/","title":{"rendered":"Smart Architectures in PHP Page 2"},"content":{"rendered":"
\n
\n
By Tim Perdue<\/div>\n
on October 10, 2000<\/div>\n<\/p><\/div>\n
\n

Pretty Pictures<\/h2>\n
\nI’ve found that managers love to have pretty pictures and diagrams
\ndrawn up for them, so here’s one that will impress the best of them.
\nThe idea behind this structure is that you are separating your logic
\nfrom the “presentation”, meaning anything complicated is going on
\ndown there in the “API\/Data Access Layer”. <\/p>\n
\nRather than coding
\nsecurity checks, update statements, etc, etc throughout your HTML
\nlayer, you should theoretically code the bulk of that in the API layer.
\nThe HTML layer will then make simple function calls that return
\neither arrays, objects, or (my favorite) database result sets.<\/div>\n
\nIf you do this right, the topmost layer will be very thin so you
\ncan easily create\/maintain it.<\/div>\n
\n\"breakdown<\/div>\n
\nDrawing from this example, the HTML interface depends on some direct
\ncalls to the API layer, some calls to an HTML utility library (which
\ncould, for example, generate pop-up boxes, or whatever), and those
\nlibraries make calls to the database using a database abstraction
\nlayer (again so you aren’t tied to any particular database).<\/div>\n<\/div>\n

<\/p>\n

\n
\u00ab Previous Page<\/a><\/div>\n
1<\/a> <\/div>\n
| <\/div>\n
2<\/div>\n
| <\/div>\n
3<\/a> <\/div>\n
| <\/div>\n
4<\/a> <\/div>\n
| <\/div>\n
5<\/a> <\/div>\n
| <\/div>\n
6<\/a> <\/div>\n
Next Page \u00bb<\/a><\/div>\n<\/div><\/div>\n
<\/p>\n