Lecture
Lazy Load Design Pattern
The object contains no data, but knows where to get it.
To download data from the database to the application's memory, it is convenient to use loading not only the data about the object, but also about the objects associated with it. This makes downloading data easier for the developer: he simply uses an object, which nevertheless has to load all the data explicitly.
But this leads to cases where a huge number of paired objects will be loaded, which will have a bad effect on performance in cases where this data is not really needed.
The Lazy Load pattern implies the refusal to load additional data when this is not necessary. Instead, a marker is placed indicating that the data is not loaded and must be loaded in case it is needed. As you know, if you are lazy, then you win in the event that a cause that you did not actually do and did not have to do.
There are four main options for lazy loading.
Identity Map Design Pattern
Provides a one-time download of the object, saving data about the object in the map of compliance. When accessing objects, it searches for them in the map of conformity.
One old adage proclaims that a person with two hours never knows what time it is. And if two clocks make confusion, then with the loading of objects from the database there can be much more confusion. If the developer is not careful enough, it may turn out that he will load the data from the database into two objects. Then, when he saves them, there will be confusion and competition for various data.
Moreover, this has performance problems. When the same information is downloaded twice, the cost of data transfer increases. Thus, the refusal to load the same data twice not only ensures the correctness of the information, but also speeds up the operation of the application.
The Identity Map pattern (Presence Card / Compliance Map) keeps records of all objects that were read from the database during the execution of a single action. When an object is accessed, a matching (presence) map is checked to see if the object is loaded.
Design Pattern Unit of Work
It serves a set of objects that are modified in a business transaction (business action) and manages the recording of changes and the resolution of data contention problems.
When it is necessary to write and read from a database, it is important to keep track of what you have changed, and if you have not changed it, do not write data to the database. It is also necessary to insert data about new objects and delete data about old ones.
You can write to the database every change of the object, but this will lead to a large number of small queries to the database, which will result in slowing down the application. Moreover, it requires keeping an open transaction all the time the application is running, which is impractical if the application processes several requests at the same time. The situation is even worse if you need to follow the reading from the database and to avoid inconsistent reading.
The implementation of the Unit of Work pattern monitors all the actions of the application that can change the database in a single business action. When the business action is completed, the Unit of Work detects all changes and makes them to the database.
Comments
To leave a comment
Web site or software design
Terms: Web site or software design