1

I should preface this by saying that although I've been programming for a while, this is the first time I'm doing it for work and am relatively new to PHP.

I have been asked to create a PHP app that, on the face of it, is quite simple - although it has some complicated business logic. Basically, it shows the user a number of cascading drop down options and then when the form is submitted it returns a set of data from a db laid out according to the business logic.

What I have so far is a number of php files containing database calls and html snippets that are ajax called by JS to display each dropdown followed by an additional file to create the resulting table of information, with all the business logic in it and more database calls.

As I'm sure you can tell, at the moment the code is mostly procedural, however as it has to be rolled out across a large number of web pages, I've been looking into different architectures to lay out the code in a more maintainable and scalable way - something I've been tryng to research for the last week and I'm no further forward.

I've been researching things such as MVC/MVP however I'm not quite getting it, as a lot of the information is conflicting and as far as I understand, it's not strictly applicable to web applications as it was originally designed for desktop apps. However, i came across a good description of the 3-Tier structure which kind of makes sense to me, namely:

  • Presentation Layer
  • Business Logic layer
  • Data Layer

However, I'm unsure how to accomplish it in practical terms. This is my thinking so far:

  • Move all the logic functions and properties to a 'business_logic' class
  • Move all the database calls to a 'data_layer' class to be instantiated in the 'business_logic' class
  • Move the code snippets to a 'view' class - possibly instantiated in the 'business_logic' class

My main question (apart from is this a good way to do it?) is should the 'business_logic' class be instantiated in a PHP filed that is called by the browser(ajax) to handle all the cascading dropdowns and the result, or should I maintain a separate file for each of these?

N.B. For the sake of shortening this question, I've left out info about the classes I have for user input validation and database connections etc. I'm also deliberately avoiding using a framework like Symfony, CodeIgniter or CakePHP as it's being put into an already existing website and it's such as small app.

Any advice or help you could offer will be gratefully appreciated!!

  • 1
    Don't know if this is applicable to your situation, but when I had to program some web pages requiring complicated price and yield calculations (for government securities), I gave up trying to do that in php, and encapsulated the calculations in a cgi written in C. Then the php code just had to construct a suitable ?query_string to be interpreted by the cgi, then let it do all the complicated work, and finally just suitably format and display the results. That approach turned out much more suitable for my purposes. – John Forkosh Sep 16 '17 at 9:40
1

The three-tier structure seems fine. However, I would try and avoid creating classes that contain an entire application layer.

Instead, split up the layers into namespaces.

In the presentation namespace, you could create classes that extract data from http requests, call the application logic and then wrap the results up in an http response (including rendered html / JSON / ...). One class for each data structure or part of the business logic should do the trick.

The business logic namespace might contain classes that each perform a specific task in the context of your application. In my experience, this is most important in the business logic layer.

Finally, the data access namespace would contain classes that facilitate the access to data structures. Each class in this namespace might map to a data structure that your application uses and do nothing except for getting the data from the DB (or other API) and return objects or arrays of objects containing that data.

Lastly, I can see why you wouldn't want to use a bloated framework. Have a look at Silex though - it doesn't prescribe any particular way of organizing your code and comes with close to nothing except for dependency injection, routing and the Symfony Request/Response classes, all of which are extremely handy (in particular for scalability) and a big hassle to implement yourself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.