Business Logic Layer's transaction script and domain model

In front of the Blog, it has been understood that the front controller, the page controller, the application controller of the three performance layer mode, if they have carefully arranged the external world and the communication within the system, then the business logic layer of the work is to process the business of the application part. The business logic layer should be away from those external "noises". The business logic is the fundamental purpose of the entire application, and the rest of the system is for this part of the service.

Two commonly used domain logic patterns are described here: Transactional scripting Patterns and domain model patterns.

One, the transaction script

1.1 Concepts

Transaction Script: Use procedures to organize business logic, each of which processes individual requests from the presentation layer. It seems a little too abstract. Most business applications can be thought of as a series of transactions, and sometimes transactions may display information about the database, and in some cases, many of the steps of the checksum calculation may be involved. A transactional script organizes all of these logic into a single process, and each transaction has its own transactional script, which has its own execution, but it is important to note that common subtasks between transactions can be decomposed into multiple sub-programs.

1.2 Why to use transactional scripting

The advantage of a transactional scripting pattern is that you can quickly get the results you want. Each script can handle the input data well and manipulate the database to ensure the desired results are obtained. It is therefore a fast and effective mechanism, and does not require a lot of time and effort in complex designs, and is suitable for smaller and more compact projects.

1.3 Implementing a Transaction script

With my work experience, many programmers are unaware of using this model, including myself before.

Now let's say that there's a business of blogging and deleting blogs , and that's a two-transaction script for each of these two businesses.

PHP code

4. //Create a base class for data processing, assuming that PDO is used
6. Abstract class Base {
8. function __construct () {
10. //Use the registry that was previously spoken by the blog
12. $dsn = \woo\base\applicationregistry::getdsn ();
14. if ( is_null( $dsn )) {
16. Throw new \woo\base\appException( "No DSN" );
18. }
22. Self::$DB = new \pdo ( $dsn );
24. Self::$DB->setattribute (\pdo::attr_errmode, \pdo::errmode_Exception);
26. }
30. protected function dostatement () {
32. //Execute SQL
34. }
36. }
40. class BlogManager extends Base {
42. Static $add _blog = "INSERT into blog (name) VALUES (?)";
44. Static $del _blog = "DELETE from blog WHERE (?)";
48. //Add Blog transaction Script
50. function addblog (...) {
52. //processing parameters, spelling add_blog formatted SQL, calling parent class Dostatement execution, notifying friends, a series of subroutines ...
54. }
58. //delete blog transaction Script
60. function delblog (...) {
62. //processing parameters, spelling del_blog formatted SQL, calling the parent class Dostatement execution.
64. }
66. }
68. ?>

This example is very simple, but just because it's simple, just reflects the advantages of the transaction script. If you write a more complex application, this way makes the project less extensible, because transactional scripts invariably infiltrate each other, leading to code duplication.

II. Domain Model

2.1 Concepts

Domain Model: It's hard to speak clearly in words. Simply put, the domain model symbolizes the individual participants in the real-world project. The principle of "all things are objects " is embodied in this very vividly. In other places objects always carry a variety of specific responsibilities, while in domain mode they are often described as a set of attributes and additional proxies. They are certain things that do something.

2.2 Why use a domain model

In real-world code, there will be a lot of transaction script patterns, you will find that duplicate code is a common problem. Repetition seems to be the quickest solution when different transactions perform the same task, but this greatly increases the cost of code maintenance. Sometimes it can be solved by refactoring, but copying and pasting slowly can be a part of the development that is difficult to avoid.

2.3 Implementing the Domain model

For comparison, reference the example of the transaction model and map the domain model class directly to the table of the relational database (this makes development simple)

PHP code

4. //Create a base class for data processing, assuming that PDO is used
6. Abstract class Base {
8. function __construct () {
10. //Use the registry that was previously spoken by the blog
12. $dsn = \woo\base\applicationregistry::getdsn ();
14. if ( is_null( $dsn )) {
16. Throw new \woo\base\appException( "No DSN" );
18. }
22. Self::$DB = new \pdo ( $dsn );
24. Self::$DB->setattribute (\pdo::attr_errmode, \pdo::errmode_Exception);
26. }
30. protected function dostatement () {
32. //Execute SQL
34. }
36. }
40. class Blogmodel extends base{
42. function addblog (...) {}
44. }
48. //Create a base class for a domain model
50. Abstract class DomainObject {
52. Private $id;
54. //$id the primary key ID for the table data
56. function __construct ( $id=null) {
58. $this->id = $id;
60. }
64. function getId () {
66. return $this->id;
68. }
72. //Keep in mind that everything is object
74. Static function getcollection ( $type ) {
76. //Gets the object to manipulate
78. }
80. }
82. class Blog extends domainobject {
84. Private $name;
86. Private $feed;
90. function __construct ( $id=null, $name=null) {
92. $this->name = $name;
94. $this->feed = self::getcollection ("\\woo\\domain\\Feed");
96. Parent::__construct ( $id );
98. }
102. function addblog (...) {
104. //Call the Blogmodel method to add
106. //call feed to send notifications to friends
108. }
112. function setfeed (feedcollection $Feed ) {
114. $this->feed = $Feed;
116. }
118. }
120. ?>

2.4 Summary

Whether a 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 a model you can focus on the problems that the system solves, while other issues, such as persistence and performance, can be resolved by other layers.

In the implementation project, most programmers put half their attention on the database when designing the domain model. Separating the domain model from the data tier leads to a cost, and you may also put the database code directly into the model (although you might use a data portal to handle the actual SQL). For relatively simple models, especially when the class corresponds to data table one by one, this approach is completely feasible and can reduce the time it takes to create an external system due to reconciling objects and databases.

The above describes the business logic layer of the transaction script and domain model, including the aspects of the content, I hope to be interested in PHP tutorial friends helpful.

