Code Design and Structure

Question

It has recently been emphasized (in my previous questions) that the way to develop web applications is not ideal.

Consider the following. I work on a multi-user website with many different sections, including profiles and forums, as well as support tickets. The structure is as follows:

On the main page, which includes all the other pages, or * required_once *, we will call it home.php.

In home.php, one of the first things loaded is router.php , it processes all the $ _GET and $ _POST that the user can produce, and each form and process is sorted using a main variable called $ data_process. Router.php is essentially one giant switch () statement for $ data_process. This analyzes all the data and gives the result.

Next, header.php is included, which not only processes the necessary variables for the page to be loaded, but also sets the title and decides exactly what will be shown there, for example. menus, user information, and information about the page being viewed (for example, Home> Support> View Tickets).

Then the page loads according to the variable $ page. Simple includes.

Then footer.php, then close.

And so a dynamic website is created. I was told that this is bad practice on behalf of @HorusKol. I am very pleased with this site, as it is the simplest and easiest to use website I have ever used. If this is still a bad code design? What is perfect code design?

PS - can anyone recommend any good easy-to-read books that explain PHP, MySQL and design structure to me?

Answer 1

• This is a bad design because you are processing a lot of data that might not be needed in the rest of the process. The router should only process the URL, mail processing is processed elsewhere. Include only what you need, including everything that slows down.
• It is best to structure the application more in different parts. A router that processes a URL, a controller that performs an action based on a routed request, a view that processes all html and pages, a model for accessing data. MVC is what comes to mind.
• There is no such thing; it is a perfect code design.

Answer 2

There is no canonical definition of "good design" - the best you can hope for is that your design will optimally balance the different forces of your project. The strengths of your project can be maintainability, performance, scalability, extensibility - classic non-functional requirements, but also such things as search engine optimization, compliance with standards and accessibility (which applies to web projects in particular).

If all your URLs are of the form "www.mysite.com/home.php?action=getDetails&productID=123", your search engine friendliness is pretty low. It is much better to have semantic URLs - "www.mysite.com/products/DesktopPc/details.php". You can achieve this by tricking .htaccess into your current project.

In terms of maintainability, your design has some problems. If I understood correctly, adding a new page to the site, you need to change the code in several different source files - router.php (your giant switch statement), the page itself and, possibly, header.php. This indicates that the code is tightly coupled . Modification of the giant switch operator sounds like a likely source of entertaining errors, and the combination of a router and a header, manipulating variables, and the actual page itself seems a little fragile. This is normal if you are the only person working on a project and you are going to be for a long time; if it is not, it is better to use ready-made frameworks (MVC is the current favorite, Zend, Symphony and Cake - all this works well in PHP), because you can specify new developers in the documentation and expect them to be up to speed.

One of the biggest opponents of maintainability is complexity - complex code is harder to work with and contains more bugs. There is a formal indicator for complexity, and I’m sure that your switch statement evaluates this metric very strongly - it’s not necessarily a huge problem in itself, but definitely something to watch out for. Many MVC infrastructures avoid this because routing is defined as data, not code (i.e., has routes in the configuration file) and / or using conditional configuration (i.e. if the request is for the productDetails page, specify the file " /inc/productDetails.inc ").

Extensibility can be another problem - imagine that you have to post the content of your site as JSON or XML, as well as HTML; in your current project, which will require significant changes, because every single element in the page processing pipeline takes care and needs to know. Home.php needs to know that it doesn't send HTML, you need to know the header and footer, the router needs to understand how to handle the extra data type, it almost certainly makes the switch statement even bigger. This again cannot be a big problem.

Both extensibility and maintainability help in the unit test of your code. Test Driven Development turns this into a common routine on its own; I suppose testing your application is difficult - but this is just an assumption; it depends more on how you accounted for individual pieces of code than what you described above. However, another advantage of MVC is that it makes it easy to write unit tests for key parts of your system.

So, if your project’s strengths do not include an emphasis on maintainability or extensibility, and you can handle the SEO aspect, I don’t think your design is necessarily “bad”; even if you take care of these things, there are other things you can do to put these forces in place - write documentation, hire a lot of cheap encoders.

The best way to speed up working with these design topics is not to book in PHP or MySQL; I would recommend Martin Fowler's Refactoring and Enterprise Application Architecture Patterns Design Patterns by Gamma et al. and Code Complete by McConnell (although this is no longer available).