PHP - How to structure this application

Question

Sorry if the title is leading.. I'm looking for advice for the following system I am implementing:

The system is to provide quotes for customers, this is then exported to PDF and emailed to the customer. Basically, the "quote" consists of the following:

• Font cover (Images - Pulled from a database)
• Attributes - (This is the actual quote)
• Header image - (Product images - Pulled from the database)
• Customers information (Customers details for the quote)
• T&C

I have made classes for each and declared an object. Which is then passed to the final object Quote but the problem is this:

I'm using PHP and the UI works so that each of these sections is a page. So, page 1 = front cover, Attributes = page 2 etc.. The final page, is where the Quote object is created and stored within the database. But, at each of the sections, the user has the ability to view the details up to this point.

I have been using sessions for this, but, now, I have 5 sessions and all of these form 1 object (which is stored as a session) - Is there a more practical way to do this? And if there is, how would I transfer the previous information to the next section?

Any advice, greatly appreciated.

Answer 1

If you want to preserve data across the pages, there are several approaches:

• The URI or the form. A wrong choice in most situations (some ASP.NET developers would disagree, pointing to view state as an example of preserving information in a form).

• Sessions. This works well for most cases if the size of the preserved data is not very large.

• Database (including Redis). The benefits, compared to sessions, is that:

  1. The size of the data is irrelevant, and doesn't impact the memory footprint of your web application.

  2. If the web application or the web server crashes, the data is still there.

  3. The data is persisted forever (well, until you decide you don't need it any longer), which is ideal for cases where you want to keep the data even if the user leaves and comes back a few days, weeks or months later.

  4. Failover/mirroring scenarios become much easier than with sessions.

From your description, it seems that you don't necessarily need the benefits of persistence inside a database. Sessions appear a good approach here.

Note that the number of sessions depends on the number of users, with one session per user. Two users—two sessions, independently of how much objects are stored in the sessions. This means that:

now, I have 5 sessions and all of these form 1 object

doesn't make too much sense. Either you are calling session something which are not an actual session, or you ended up thinking that there are multiple sessions, where there is only one.