I am currently implementing a system and I have a question regarding the interaction between different elements in the system with the class that interacts directly with the database (the one opening and closing connections, executing sql queries, etc).
So far, my Business Logic Layer is deferring the construction of all SQL queries (depending on certain inputs) to my Database Access Layer, which in turn would call the database-handling class to execute each query. Note that right above my Business Logic Layer is the GUI.
The question is: would it be bad practice to include the construction of SQL queries in the Business Logic Layer? I am asking this because I need to implement a procedure that gets data from database DB1, manipulates it, and then writes it into DB2. Thus I find that hardcoding these SQL queries would be easier to keep in my business layer.
Please let me know your thoughts and if this is a clean design to some extent from an architectural point of view, or if I should include this logic all in my Database Access Layer.
would it be bad practice to include the construction of SQL queries in the Business Logic Layer?
Most likely. The business layer should generally be database-agnostic.
I need to implement a procedure that gets data from database DB1, manipulates it, and then writes it into DB2
So you need two data layer objects - one to get the data from DB1 and one to save it in DB2. The "manipulation" can be done in either place (business layer or data layer), depending on the nature of the manipulation. For example, is it purely a data conversion, or does it depend on other aspects of the business layer?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With