I have a 3-tiered web application with a web view layer, a business logic layer, and a database persistence layer. I am adding a feature that populates a history table with records if and only if the element being saved has changed (it compares the previous and current records and saves the history records if anything has changed).
I’m not sure if the logic of building the history records and saving them belongs in the business logic layer or the database persistence layer. The database persistence layer has a single saveElement method. The business logic layer has multiple places that call the database persistence’s saveElement method.
Advantage of placing the history logic in the database persistence layer:
-If the logic were placed in the business logic layer, there is a risk that some of the business logic layer callers would forget to call the method to create the history records. If the logic was placed in the database persistence layer, any saved record is guaranteed to have a history record created.
-The site has another history system for other information that is in the database layer and it would create consistency if both systems were located in the same place.
Advantage of placing the history logic in the business logic layer:
-There is a bit of complexity in building the history records and the database layer is mainly used for calling/running sql queries.
So is there any compelling reason to place this logic in either the business logic layer or the database layer? Or does it not matter where the logic is placed?
3
It depends.
Specifically, it depends on the logical level you would like to remember changes for. If “element changed” is a sensible history record, and you already have saveElement in the persistence layer, then extending saveElement to also log the change to a historical/archive record makes sense.
However, if you are trying to archive business-level events like “purchased inventory for project 4017” at a higher level than the elements you’re storing, you will need to do that in the business layer, because that’s where the intention of the activity is understood.
This is a classic layering issue: “where is the intention information available?” Often the straightforward answer (e.g. “we want to save history information and we already have a persistence layer, so that’s where it should go!”) is, if not incorrect, made dramatically less clear by higher layers decomposing their activities, and calling the persistence layer as more of a “save this!” workhorse. Higher level concepts are often unavailable by the time they filter down to persistence layers. At a minimum, then, you would need to adjust the API between the layers to allow the business layer to declare its intent (such as “for project X”) as it calls saveElement.