Where is our business logic for an idealist?
In this article I will try to understand myself and my arguments. To begin with, I will try to oppose the author of the article, the translation of which I found on a habr. Where is our business logic, son? . She wrote the same idealist, which I was 10 years ago. Therefore, in essence in this article I will argue with myself. The fact is that the more applications I develop, the more beautiful theories cease to fit into ideal schemes. Ideal schemes are good because they are simple. You are asked where is the business layer? And you can easily say on the client side or on the server side. If mixed pointedly twist his nose and say "shit code". I do not agree with this. The real world does not invest in idealistic concepts, more precisely, it can be shoved there, but we will lose from this more likely. Therefore, at first, subconsciously, I understood that there are different cases. And now I am trying to formulate more and more what influences this or that decision on the placement of business logic. Here we leave the beautiful theories without argumentation to the young utopians who want simple solutions.
')
The author of this article writes:
and writes about it as a definition. It only proves when it talks about a client-server architecture:
So the controversy is tied. It turns out that " business logic began to move to the middle link because development languages ​​(C ++, VB, Delphi, Java) were much better suited for implementing business logic ." But what characteristics of the mentioned development languages ​​are better than the procedural language SQL? Conditions and cycles, division into procedures is also in SQL. This SQL is no different from any procedural language, such as C ++, VB, Delphi, until object methodology comes into play. Therefore, the statement “the languages ​​of stored procedures were developed for quick execution and not for servicing complex tasks of business logic” is very superficial and quite controversial.
The SQL language in terms of managing procedural logic is no different from other languages. But it really does not implement the object methodology, which allows you to manage more complex logic. Therefore, we will argue from here that if you do not use the object methodology for managing business logic, you should not care what the algorithms are written in - in SQL or C. And accordingly, absolutely no difference whether the server is so-called. the middle layer is, say, C, which will access the database, using it as a storage, or in the database there will be SQL stored procedures, which will also access data tables. The latter is even preferable, since eliminates excess layer.
But I stress that all this is true only for non-object languages. When we want to take advantage of object methodology, only then we go to separate the data in the database from business logic, and business logic to manage separately and in another language other than SQL.
When the author of the article writes " The database server is the storage level. The databases are designed to store, retrieve and update data with the highest possible efficiency. ... The database should not care what the customer is, it should only care about the elements used for the customer’s storage. The database should not be able to figure out which tables the customer should store, and it should work with the tables regardless of the customer’s object. ”- it’s not entirely accurate. The database server, of course, performs the task of storing data, but this is not its only task. The database server also processes the data. The author wants to reduce data processing to elementary operations insert, update, delete on one table and tell us that everything else is business logic that needs to be separated.
But he forgets that the implementation data model represents the data in the so-called. 3rd normal form to eliminate data storage redundancy. This alone suggests that the data in the database is not stored in one table, but is relationally decomposed over a set of tables. And it is absolutely not possible to update the data about the "buyer" using only one table. The author does not explicitly speak about object methodology, but uses the word “object buyer”. I think it is superfluous to say that the customer object does not directly correspond to the customers table. The buyer object is usually selected by a complex select from the set of linked (join) tables. And how does it represent the update of the data object of the buyer? Will it be in business logic, with its restriction on working with a single table in SQL, to deal with the logic of storing relational data? It is this kind of logic for storing customer object data in several relational tables that is obvious and should be implemented in one stored procedure.
We must also agree that the data stored in the database tables are primary data, and what we pull out of it for processing or for display to the user is secondary data. So when we talk about business logic, we need to be aware that when we were developing a relational data model, we already set some of the rules of business logic. The data storage model already imposes certain conditions on the logic business model. With the help of stored procedures, we can abstract away from the method of data storage, and then provide data to the outside in terms of objects, not relational tables. Then the business logic will work with the secondary data in the object methodology.
In these two sections, for the time being, I simply removed the excesses that the author insisted on, and I think there are his followers. Next, we will go further and see in which cases it is effective and in which it is not effective to use the object methodology of working with business logic.
With the amendments made above, I implemented quite a few applications with the separation of the relational data model and the objective model of business logic. But my slender world once significantly shaken.
One of the applications that I implemented was the implementation of the payment system in banks. In essence, this is one form representing a payment order form. Among other things, this form was able to implement the so-called. passing conversions. Moreover, the conversions could be different: when there is not enough money for the payment, it should be proposed to convert from another currency, and the amount and commission for the payment can be converted from different currencies, you can take overdraft on the payment, and convert the tariff, you can partially pay what you have, and convert the missing amount, etc. quite complex business logic rather rigidly intertwined with the user interface.
But one of the customers one day wanted the payment orders to be processed and carried out automatically in the system, and the payment order needed to be checked for compliance with a number of requirements, if there is not enough money just like before, in a dialogue with a bank employee, create a conversion or take overdraft, but this time it was necessary to exclude from this process a bank employee completely. Priorities of currencies were established - in what order to convert, in what cases, what and how allowed, and in what cases to issue for checking to a bank employee. The goal is quite understandable in 90% of cases a bank employee was completely unloaded from the work of verifying payment orders.
So, there was a simple question - in the user's dialogue in 90% of cases, there was no need. If we assume that we have previously well separated the user interface from business logic, then we have already implemented business logic in a complex set of objects. The only problem is that the initiation of the work of this business logic was oriented towards the user's dialogue. And now we had to choose payment orders from the database, replace the initiation logic of the user dialogue with another automatic processing logic, process the already existing logic, and write the completed payment order back to the database. Moreover, posting a payment order is an automatic creation of a balance sheet and another complicated procedure. And do not forget to still convert, overdrafts, which are reflected in the balance sheet of course separate documents and other articles.
The question is - why should all this information be pumped out of the database, processed and written back? There is no such need at all, since User is completely excluded from automatic payment processing. Accordingly, all this can be solved at the level of data processing, which the database server is fully engaged in.
But after all, the fact that we previously identified business logic in object methodology was not at all useful to us, since we just need to have one stored procedure that simply carries out a payment order from the queue. Yes, in this case, the business logic falls into stored procedures.
For the client-server architecture, there is no alternative here - this is an example of how the logic, if it was necessary in the client, migrates to the server, and the duplication remains in the client, although it would be more logical to transfer the common business logic to the server to a stored procedure, leaving only client services to the client. user interface.
3-tier architecture, assumes that business logic is on the server (middle link) and for this task passes the client. But first, we introduced an extra link, and secondly, it again performs the role of a client in this task - it pumps data from the database, processes it and writes it back. And all this only in order to be convenient in the object language to handle business logic. Isn't the price high?
The second case was not long in coming. It was necessary to implement a system of utility payments. In fact, this is another add-on over the payment system. Utility payments contain some additional specific information, such as a description of the service, meter readings, debts, and a number of technical information about the system through which they are paid, how often, etc. And only then, on the basis of the communal order, this payment order is created. The function of the bank here is to save money from various channels of payment receipt for services and to make a transfer to the account of the service provider in one consolidated payment. Therefore, utility orders with payment orders attached to them are collected in packages. And again, the packages receive instructions for a specific business logic, and again, there is no user interface. Packages are formed automatically according to certain criteria. And the world rotates without user intervention.
Now, taught by the fact that business logic is effective in the database, the logic of forming a real payment on the basis of a communal order was carried out by a stored procedure. Moreover, it was used both when creating a communal order through the interface, and also as an API to external (for example, accounting) programs in relation to the banking system, as well as accepting communal orders through the Internet bank. Would this be possible if business logic were not in a stored procedure, but, for example, in objects in C #? Yes, it is possible, but by introducing a completely unnecessary middle link with duplication of methods for obtaining / writing data into the database.
But when we reach the packages, the business logic dictates that we need to select payments based on certain attributes, affix the same characteristics (such as the package’s belonging, status, textual explanation to the user) to a large set of payments, calculate the total amount and number of payments in the package using functions SUM (), COUNT () ... and I would be very surprised if all this would be implemented in an object-oriented methodology, and not using SQL. And when, in conclusion, after forming a package, it is necessary to form a consolidated payment, and not being able to form it from SQL - is this really the merit of the fact that the business logic is not in the database?
I think these two examples are enough to understand that finding business logic in database stored procedures is more than justified, and in some cases is even necessary.
And the fact is that in essence there are two kinds of business logic. One business logic determines how to interact with the user, and the other relates to batch processing. In the first case, it is really convenient to manage business logic on the client or middle level in the object language, and secondly, with automatic, batch processing, it makes sense to work on the primary data rather than on the secondary data, without first sending them from the database and not writing back.
If the author of the article under discussion expresses (in my opinion not reasonably enough) one extreme point of view, according to which there should not be business logic in the database. So you can express another extreme point of view, according to which all business logic can be in the database. The only thing we lose in this case is the lack of an objective methodology in working with business logic.
When can this be justified?
Not so long ago, I wrote about my startup for creating a browser game. And there really is used such an approach - all business logic in the database. What caused this?
Web development is still quite specific - the client is the browser and is always controlled by another scripting language (JavaScript). And the task of the server is reduced to the formation of HTML pages for the client. In this regard, we have lost the ability to control the client using an object-oriented language (unless we consider JavaScript as an object language, which it is not fully). Accordingly, the main incentive to pull data from the base disappears in order to create a business model outside the base in the client.
Almost the same on the server. Here, of course, we are not devoid of object methodology, for example, if we use ASP.NET. But the task of the server is reduced to the formation of HTML - pages. More specifically, to the filling of HTML pages with data, which are obtained by stored procedures, as a rule, by a simple select query. Yes, of course, there are still reactions to button presses and clicks on check boxes, etc. But unlike office applications with forms, where a fairly complex logic of user interaction is carried out, web pages are extremely simplified, since the reaction is usually reduced to the formation of another HTML - page with other data.
In the bare remnant, in web applications remain tasks that are performed "behind the scenes". For example, in the browser game (economic strategy with RPG elements), which I implement are such tasks as checking the production process for creating products, calculating market characteristics (purchase prices), making purchases, election in guilds, making long-term supplies and tons .P. All of them are executed with a certain periodicity in the game, they make up 60-80% of all business logic, and they all occur “behind the scenes” of the player. And it would be strange if, in order to carry out these tasks, we had to pull out the primary data and present them as an object model, only then, to write this data back after processing. Data selections (select queries) are implemented in one way or another by stored procedures.
There are only reactions to button presses, and other relationships with the interface. But for JavaScripta again, it all comes down to getting a piece of data, and writing client algorithms, which can hardly be called business logic, is more like an interface mapping logic. And to leave the business logic that will serve the interactive work with the user through the HTML pages in the object model, but because of the simplicity of this interactivity, this is more costly than any advantage.
So it turns out that for web applications almost all business logic is in the database. This again allows the core of the game to operate independently in the database, regardless of the operation of the web server. Allows you to write any other clients, referring to stored procedures as an API. The minus remains only in one thing - it is not very convenient to implement business logic without an object language, but since this is often the logic of working not with one object, but again it is group operations with many entities in the database, it is not so simple.
There are simply no other architectural disadvantages, the presence of business logic in the database.
Object and procedural programming in light of databases
')
The author of this article writes:
... let's clearly define: what is business logic. ... A database server is a storage level. Databases are designed to store, retrieve and update data with the highest possible efficiency. ... A database should not be concerned with what a customer is, it should only care about the elements used to store the customer. The database should not be able to figure out which tables the customer should store, and it should work with the tables without paying attention to the customer. The task of the database is to store rows in tables that describe the customer. In addition to basic constraints such as cascade integrity, data types, indexes, and null values, the database should not have functional knowledge about what the buyer is in the business layer.
and writes about it as a definition. It only proves when it talks about a client-server architecture:
It quickly became clear that it was possible to reduce the load on the network and centralize logic to reduce fixed deployment costs by transferring most of the business logic to the server. Architecturally, the server was a well-prepared place in the client-server system, but the database as a platform offered few opportunities. The databases were designed for storage and distribution, and their architecture did not allow for expansion in the direction of business logic. Database stored languages ​​have been developed for basic data transformations to support something that was missing from SQL. The stored procedure languages ​​have developed a business logic for quick execution and not for handling complex tasks.
In most cases, the middle link existed only for managing the connection pool, but in some cases the business logic began to move to the middle link because the development languages ​​(C ++, VB, Delphi, Java) were much better suited for implementing business logic than the stored procedure languages. It soon became apparent that the middle link is the best place for business logic.
So the controversy is tied. It turns out that " business logic began to move to the middle link because development languages ​​(C ++, VB, Delphi, Java) were much better suited for implementing business logic ." But what characteristics of the mentioned development languages ​​are better than the procedural language SQL? Conditions and cycles, division into procedures is also in SQL. This SQL is no different from any procedural language, such as C ++, VB, Delphi, until object methodology comes into play. Therefore, the statement “the languages ​​of stored procedures were developed for quick execution and not for servicing complex tasks of business logic” is very superficial and quite controversial.
The SQL language in terms of managing procedural logic is no different from other languages. But it really does not implement the object methodology, which allows you to manage more complex logic. Therefore, we will argue from here that if you do not use the object methodology for managing business logic, you should not care what the algorithms are written in - in SQL or C. And accordingly, absolutely no difference whether the server is so-called. the middle layer is, say, C, which will access the database, using it as a storage, or in the database there will be SQL stored procedures, which will also access data tables. The latter is even preferable, since eliminates excess layer.
But I stress that all this is true only for non-object languages. When we want to take advantage of object methodology, only then we go to separate the data in the database from business logic, and business logic to manage separately and in another language other than SQL.
The relational database model is part of business logic.
When the author of the article writes " The database server is the storage level. The databases are designed to store, retrieve and update data with the highest possible efficiency. ... The database should not care what the customer is, it should only care about the elements used for the customer’s storage. The database should not be able to figure out which tables the customer should store, and it should work with the tables regardless of the customer’s object. ”- it’s not entirely accurate. The database server, of course, performs the task of storing data, but this is not its only task. The database server also processes the data. The author wants to reduce data processing to elementary operations insert, update, delete on one table and tell us that everything else is business logic that needs to be separated.
But he forgets that the implementation data model represents the data in the so-called. 3rd normal form to eliminate data storage redundancy. This alone suggests that the data in the database is not stored in one table, but is relationally decomposed over a set of tables. And it is absolutely not possible to update the data about the "buyer" using only one table. The author does not explicitly speak about object methodology, but uses the word “object buyer”. I think it is superfluous to say that the customer object does not directly correspond to the customers table. The buyer object is usually selected by a complex select from the set of linked (join) tables. And how does it represent the update of the data object of the buyer? Will it be in business logic, with its restriction on working with a single table in SQL, to deal with the logic of storing relational data? It is this kind of logic for storing customer object data in several relational tables that is obvious and should be implemented in one stored procedure.
We must also agree that the data stored in the database tables are primary data, and what we pull out of it for processing or for display to the user is secondary data. So when we talk about business logic, we need to be aware that when we were developing a relational data model, we already set some of the rules of business logic. The data storage model already imposes certain conditions on the logic business model. With the help of stored procedures, we can abstract away from the method of data storage, and then provide data to the outside in terms of objects, not relational tables. Then the business logic will work with the secondary data in the object methodology.
In these two sections, for the time being, I simply removed the excesses that the author insisted on, and I think there are his followers. Next, we will go further and see in which cases it is effective and in which it is not effective to use the object methodology of working with business logic.
Shatter the world of the idealist
With the amendments made above, I implemented quite a few applications with the separation of the relational data model and the objective model of business logic. But my slender world once significantly shaken.
One of the applications that I implemented was the implementation of the payment system in banks. In essence, this is one form representing a payment order form. Among other things, this form was able to implement the so-called. passing conversions. Moreover, the conversions could be different: when there is not enough money for the payment, it should be proposed to convert from another currency, and the amount and commission for the payment can be converted from different currencies, you can take overdraft on the payment, and convert the tariff, you can partially pay what you have, and convert the missing amount, etc. quite complex business logic rather rigidly intertwined with the user interface.
But one of the customers one day wanted the payment orders to be processed and carried out automatically in the system, and the payment order needed to be checked for compliance with a number of requirements, if there is not enough money just like before, in a dialogue with a bank employee, create a conversion or take overdraft, but this time it was necessary to exclude from this process a bank employee completely. Priorities of currencies were established - in what order to convert, in what cases, what and how allowed, and in what cases to issue for checking to a bank employee. The goal is quite understandable in 90% of cases a bank employee was completely unloaded from the work of verifying payment orders.
So, there was a simple question - in the user's dialogue in 90% of cases, there was no need. If we assume that we have previously well separated the user interface from business logic, then we have already implemented business logic in a complex set of objects. The only problem is that the initiation of the work of this business logic was oriented towards the user's dialogue. And now we had to choose payment orders from the database, replace the initiation logic of the user dialogue with another automatic processing logic, process the already existing logic, and write the completed payment order back to the database. Moreover, posting a payment order is an automatic creation of a balance sheet and another complicated procedure. And do not forget to still convert, overdrafts, which are reflected in the balance sheet of course separate documents and other articles.
The question is - why should all this information be pumped out of the database, processed and written back? There is no such need at all, since User is completely excluded from automatic payment processing. Accordingly, all this can be solved at the level of data processing, which the database server is fully engaged in.
But after all, the fact that we previously identified business logic in object methodology was not at all useful to us, since we just need to have one stored procedure that simply carries out a payment order from the queue. Yes, in this case, the business logic falls into stored procedures.
For the client-server architecture, there is no alternative here - this is an example of how the logic, if it was necessary in the client, migrates to the server, and the duplication remains in the client, although it would be more logical to transfer the common business logic to the server to a stored procedure, leaving only client services to the client. user interface.
3-tier architecture, assumes that business logic is on the server (middle link) and for this task passes the client. But first, we introduced an extra link, and secondly, it again performs the role of a client in this task - it pumps data from the database, processes it and writes it back. And all this only in order to be convenient in the object language to handle business logic. Isn't the price high?
The second case was not long in coming. It was necessary to implement a system of utility payments. In fact, this is another add-on over the payment system. Utility payments contain some additional specific information, such as a description of the service, meter readings, debts, and a number of technical information about the system through which they are paid, how often, etc. And only then, on the basis of the communal order, this payment order is created. The function of the bank here is to save money from various channels of payment receipt for services and to make a transfer to the account of the service provider in one consolidated payment. Therefore, utility orders with payment orders attached to them are collected in packages. And again, the packages receive instructions for a specific business logic, and again, there is no user interface. Packages are formed automatically according to certain criteria. And the world rotates without user intervention.
Now, taught by the fact that business logic is effective in the database, the logic of forming a real payment on the basis of a communal order was carried out by a stored procedure. Moreover, it was used both when creating a communal order through the interface, and also as an API to external (for example, accounting) programs in relation to the banking system, as well as accepting communal orders through the Internet bank. Would this be possible if business logic were not in a stored procedure, but, for example, in objects in C #? Yes, it is possible, but by introducing a completely unnecessary middle link with duplication of methods for obtaining / writing data into the database.
But when we reach the packages, the business logic dictates that we need to select payments based on certain attributes, affix the same characteristics (such as the package’s belonging, status, textual explanation to the user) to a large set of payments, calculate the total amount and number of payments in the package using functions SUM (), COUNT () ... and I would be very surprised if all this would be implemented in an object-oriented methodology, and not using SQL. And when, in conclusion, after forming a package, it is necessary to form a consolidated payment, and not being able to form it from SQL - is this really the merit of the fact that the business logic is not in the database?
I think these two examples are enough to understand that finding business logic in database stored procedures is more than justified, and in some cases is even necessary.
And the fact is that in essence there are two kinds of business logic. One business logic determines how to interact with the user, and the other relates to batch processing. In the first case, it is really convenient to manage business logic on the client or middle level in the object language, and secondly, with automatic, batch processing, it makes sense to work on the primary data rather than on the secondary data, without first sending them from the database and not writing back.
Other extreme point of view
If the author of the article under discussion expresses (in my opinion not reasonably enough) one extreme point of view, according to which there should not be business logic in the database. So you can express another extreme point of view, according to which all business logic can be in the database. The only thing we lose in this case is the lack of an objective methodology in working with business logic.
When can this be justified?
Not so long ago, I wrote about my startup for creating a browser game. And there really is used such an approach - all business logic in the database. What caused this?
Web development is still quite specific - the client is the browser and is always controlled by another scripting language (JavaScript). And the task of the server is reduced to the formation of HTML pages for the client. In this regard, we have lost the ability to control the client using an object-oriented language (unless we consider JavaScript as an object language, which it is not fully). Accordingly, the main incentive to pull data from the base disappears in order to create a business model outside the base in the client.
Almost the same on the server. Here, of course, we are not devoid of object methodology, for example, if we use ASP.NET. But the task of the server is reduced to the formation of HTML - pages. More specifically, to the filling of HTML pages with data, which are obtained by stored procedures, as a rule, by a simple select query. Yes, of course, there are still reactions to button presses and clicks on check boxes, etc. But unlike office applications with forms, where a fairly complex logic of user interaction is carried out, web pages are extremely simplified, since the reaction is usually reduced to the formation of another HTML - page with other data.
In the bare remnant, in web applications remain tasks that are performed "behind the scenes". For example, in the browser game (economic strategy with RPG elements), which I implement are such tasks as checking the production process for creating products, calculating market characteristics (purchase prices), making purchases, election in guilds, making long-term supplies and tons .P. All of them are executed with a certain periodicity in the game, they make up 60-80% of all business logic, and they all occur “behind the scenes” of the player. And it would be strange if, in order to carry out these tasks, we had to pull out the primary data and present them as an object model, only then, to write this data back after processing. Data selections (select queries) are implemented in one way or another by stored procedures.
There are only reactions to button presses, and other relationships with the interface. But for JavaScripta again, it all comes down to getting a piece of data, and writing client algorithms, which can hardly be called business logic, is more like an interface mapping logic. And to leave the business logic that will serve the interactive work with the user through the HTML pages in the object model, but because of the simplicity of this interactivity, this is more costly than any advantage.
So it turns out that for web applications almost all business logic is in the database. This again allows the core of the game to operate independently in the database, regardless of the operation of the web server. Allows you to write any other clients, referring to stored procedures as an API. The minus remains only in one thing - it is not very convenient to implement business logic without an object language, but since this is often the logic of working not with one object, but again it is group operations with many entities in the database, it is not so simple.
There are simply no other architectural disadvantages, the presence of business logic in the database.
Source: https://habr.com/ru/post/219445/
All Articles