Transaction script and domain model of business logic layer

In the previous blog, we have learned about the three presentation layer modes of front-end controller, page controller, and application controller. If they carefully arrange the communication between the external world and the inside of the system, then the work of the business logic layer It is the business part that handles the application. The business logic layer should be kept away from external "noise". Business logic is the fundamental purpose of the entire application, and other parts of the system serve this part.

Here are two commonly used domain logic patterns: transaction script pattern and domain model pattern.

1. Transaction Script

1.1 Concept

Transaction Script: Use processes to organize business logic, and each process handles a single request from the presentation layer. It seems a bit too abstract. Most business applications can be viewed as a series of transactions. Sometimes, a transaction may simply display database information, and sometimes it may involve many checksum calculation steps. Transaction scripts organize all this logic into a single process, and each transaction has its own transaction script, which means it has its own execution process. However, note that common subtasks between transactions can be decomposed into multiple subroutines.

1.2 Why use transaction scripts

The advantage of transaction script mode is that you can get the results you want quickly. Each script handles the input data well and manipulates the database to ensure the desired results. Therefore, it is a fast and effective mechanism that does not require investing a lot of time and energy in complex design. It is perfect for small projects with tight deadlines.

1.3 Implementing transaction scripts

Based on my work experience, many programmers are using this pattern without knowing it, including myself before.

Now suppose that there is a business of publishing blog and deleting blog, then treat these two businesses as two transaction scripts respectively.

Php code

2. //Create a base class here for data processing, assuming that pdo is used
3. abstract class Base
function
4. __construct { $dsn = woobaseApplicationRegistry::getDSN( );
5.                                                                                                                                                                                           "No DSN" );
6. }
7. $dsn ); self::$DB
->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_
8. Exception); functiondoStatement() { Execute sql
9. }
10. }
11. static $add_blog = "INSERT INTO blog (name) values(?)"
;
12. static$del_blog
=
13. "DELETE FROM blog WHERE (?)";
15. //Add blogtransaction script
16. function addBlog(...) {
//Process parameters, spell sql in add_blog format, call the parent class doStatement to execute, notify friends, and a series of subroutines. . .
19. }
20. delBlog(...) {
21.           // Processing parameters, spelling del_blog Format sql, call the parent class doStatement to execute. }
22. } ?> If you are writing a more complex application, this approach makes the project less scalable because transaction scripts inevitably bleed into each other, resulting in code duplication. 2. Domain Model
23. 2.1 Concept
Domain Model: It is difficult to explain clearly in words. Simply put, the domain model symbolizes the various participants in the project in the real world. The principle of "everything is an
24. object" is most vividly reflected here. Elsewhere objects always carry various specific responsibilities, but in domain patterns, they are often described as a set of properties and attached agents. They are certain things that do certain things. 2.2 Why use domain model
In real code, there will be many transaction script patterns, and you will find that duplicate code is a common problem. When different transactions want to perform the same task, duplication seems to be the fastest solution, but this greatly increases the cost of code maintenance. Sometimes it can be solved by refactoring, but slowly copy-pasting may become an unavoidable part of development.

25. 2.3 Implementing the domain model

    To achieve comparison, quote the example of the transaction model, and map the domain model class directly to the table of the relational database (doing this will make development simpler)

    Php code

    2. //Create a base class here for data processing, assuming that pdo is used
    3. abstract class Base
    function
    4. __construct { );
    if
    5. (is_null($dsn)) {
    6.                                                                                                      :$DB =
    new
    7. PDO($dsn); self::$DB->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_
    Exception
    8. ); }
    9. protected
    function
    10. doStatement() {
    11. } }
    class D Blogmodel
    13. Extends Base {
    14. Function addblog (...) {}}}
    abstract
    22. class DomainObject {
    private
    24. $id;
    25. function __construct($id
    = null ) {
    26.                                                                                                                functiongetId() {
    27. return$ this
    ->id;
    28. }
    29. static function
    getCollection(
    30. $type) {
    31.               //Get the
    object to be operated on 
    32.                                  DomainObject {
    33. private $name;
    34. private $feed
    ;
    36. function__construct($id
    =null,
    37. $name=null) { $this->name = $name
    ;
    38. $id ) ;
    39. }
    41. function addBlog(...){
    42. //Call the feed to send notifications to friends
    43. }
    45. function setFeed(FeedCollection $Feed
    ) {
    46. $Feed;
    47. } }
    48. ?>
    49. 2.4 Summary
    50. Whether the domain model is designed to be simple or complex depends on the complexity of the business logic. The advantage of using a domain model is that when you design the model, you can focus on the problems that the system wants to solve, while other problems (such as persistence and performance, etc.) can be solved by other layers. In implementation projects, most programmers still focus half of their attention on the database when designing the domain model. Separating the domain model from the data layer comes at a cost, and you might as well put the database code directly into the model (although you might use a data entry to handle the actual SQL). For relatively simple models, especially when classes correspond to data tables one-to-one, this method is completely feasible and can reduce the time consumption caused by creating external systems for coordinating objects and databases.
    The above introduces the transaction script and domain model of the business logic layer, including the content. I hope it will be helpful to friends who are interested in PHP tutorials.