This is quite a general question regarding software design in a web application supposed to run on an intranet of a company. The basic design is simple: I have a backend (PHP) on a server, where a database (MySQL) is holding all data for the application. The application is used in a company and shall reflect employee related tasks. The frontend webpage (HTML, CSS) shows a UI for manipulating employee data etc.
A basic business object is here the employee, which is represented by a PHP class. When the frontend asks to show data for an employee, the query goes to the php class, which loads the employee data from database, instantiates an employee object and sends the employee data back to the client. Further queries from the client involve some logic that is done in the employee object, so I wanted to keep the just instantiated employee object in memory and use it again. I wanted to avoid the database access to load the employee data, instantiate object every time the client does a request.
So I created an object manager in PHP on server side which should store already instantiated business objects and provide them on demand or load objects required at the moment they are needed (lazy loading). But I realized that (of course) the server does not keep instances in memory between different http requests from the client, so my object manager does not work. In a desktop application this would work, but not in a web application. Is this a bad approach for web application design? Is it normal that business objects are loaded and instantiated on every client request?
Another possibility is to describe and instantiate employee objects in javascript class and do this logic on the client side where objects can be kept in memory, isn't it? But I thought it is better to do business logic on the server to not stress the client to much.
I wanted to avoid the database access to load the employee data, instantiate object every time the client does a request.
You are headed for a great deal of complexity if this is really a requirement in your environment. I would benchmark the actual cost of just re-reading the data and judge if the added complexity is really needed.
You are trying to implement an object cache. If you solve the issue of keeping the object in memory between HTTP requests (it can be done), you will soon discover questions of concurrency (multiple clients acting on objects that you have cached) and the issue of transactionality (changes to the object cache must be written to the database in a transactionally consistent manner, among other issues.
If you really need this functionality, look into existing object cache implementations.