Transaction scripts and domain models at the business logic layer

: This article mainly introduces the transaction script and domain model at the business logic layer. For more information about PHP tutorials, see. Previous BlogYou have learned about the frontend controller, page controller, and application controller. if they have carefully arranged the communication between the external world and the system, the business logic layer is used to process the application's business. The business logic layer should stay away from those external "noises ". Business logic is the fundamental purpose of the entire application, and other parts of the system serve this part.

Here we will introduce two commonly used domain logic modes: transaction script mode and domain model mode.

I. transaction script

1.1 Concepts

Transaction Script: processes are used to organize business logic. each process processes a single request from the presentation layer. It seems a little abstract. Most business applications can be considered as a series of transactions. sometimes, transactions may display the database information, and sometimes may involve many checksum calculation steps. The transaction script organizes all these logics into a single process, and each transaction has its own transaction script, that is, it has its own execution process, note that common subtasks between transactions can be divided into multiple subprograms.

1.2 Why use transaction scripts

The advantage of the transaction script mode is that you can quickly get the desired results. Each script can process input data well and operate the database to ensure desired results. Therefore, it is a fast and effective mechanism, and does not need to invest a lot of time and effort in complex design. it is not suitable for small and tight projects.

1.3 implement transaction scripts

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

Now suppose there is a postBlogAnd deleteBlogThe two services are considered as two transaction scripts respectively.

Php code

2. // Create a base class for data processing. assume that pdo is used.
3. Abstract class Base {
4. Function _ construct (){
5. // Before this is usedBlogLecture Registry
6. $ Dsn = \ woo \ base \ApplicationRegistry: getDSN ();
7. If (is_null ($ dsn )){
8. Throw new \ woo \ base \ AppException("No DSN ");
9. }
11. Self: $ DB = new \ PDO ($ dsn );
12. Self: $ DB-> setAttribute (\ PDO: ATTR_ERRMODE, \ PDO: ERRMODE _Exception);
13. }
15. Protected function doStatement (){
16. // Execute SQL
17. }
18. }
20. Class blogManager extends Base {
21. Static $ add_blog = "insert into blog (name) values (? )";
22. Static $ del_blog = "delete from blog WHERE (?) ";
24. // AddBlogTransaction script
25. Function addBlog (...){
26. // Processing parameters, spelling SQL statements in add_blog format, calling the parent class doStatement for execution, notifying friends, and a series of subprograms...
27. }
29. // DeleteBlogTransaction script
30. Function delBlog (...){
31. // Process parameters, spelling SQL statements in del_blog format, and calling the parent class doStatement for execution.
32. }
33. }
34. ?>

This example is very simple, but it just reflects the advantages of transaction scripts because of its simplicity. If you write a more complex application, this method makes the project not easily scalable, because the transaction scripts always inevitably penetrate into each other, leading to code duplication.

2. domain model

2.1 Concepts

Domain Model: it is difficult to express clearly. Simply put, the domain model symbolizes various participants in projects in the real world. "EverythingObjectThe principle is fully embodied here. ElsewhereObjectThere are always various specific responsibilities. in the domain model, they are often described as a group of attributes and additional proxies. They are something that does something.

2.2 Why use domain models

In actual code, there will be many transaction script modes, and it will be found that repeated code is a common problem. When different transactions need to execute the same task, repetition seems to be the fastest solution, but this greatly increases the cost of code maintenance. Sometimes it can be solved through refactoring, but slowly copying and pasting may become an inevitable part of development.

2.3 implement domain model

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

Php code

2. // Create a base class for data processing. assume that pdo is used.
3. Abstract class Base {
4. Function _ construct (){
5. // Before this is usedBlogLecture Registry
6. $ Dsn = \ woo \ base \ApplicationRegistry: getDSN ();
7. If (is_null ($ dsn )){
8. Throw new \ woo \ base \ AppException("No DSN ");
9. }
11. Self: $ DB = new \ PDO ($ dsn );
12. Self: $ DB-> setAttribute (\ PDO: ATTR_ERRMODE, \ PDO: ERRMODE _Exception);
13. }
15. Protected function doStatement (){
16. // Execute SQL
17. }
18. }
20. Class blogModel extends Base {
21. Function addBlog (...){}
22. }
24. // Create a base class for the domain model
25. Abstract class DomainObject {
26. Private $ id;
27. // $ Id is the primary key id of the table data
28. Function _ construct ($ id = null ){
29. $ This-> id = $ id;
30. }
32. Function getId (){
33. Return $ this-> id;
34. }
36. // Keep everything in mindObject
37. Static function getCollection ($ type ){
38. // ObtainObject
39. }
40. }
41. Class Blog extends DomainObject {
42. Private $ name;
43. Private $ feed;
45. Function _ construct ($ id = null, $ name = null ){
46. $ This-> name = $ name;
47. $ This-> feed = self: getCollection ("\ woo \ domain \ Feed ");
48. Parent: :__ construct ($ id );
49. }
51. Function addBlog (...){
52. // Call the blogModel method to add
53. // Call the feed to send a notification to a friend.
54. }
56. Function setFeed (FeedCollection $ Feed ){
57. $ This-> feed = $ Feed;
58. }
59. }
60. ?>

Conclusion 2.4

The simplicity or complexity of the domain model 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 to be solved by the system, while other problems (such as persistence and performance) can be solved by other layers.

In implementation projects, most programmers focus half of their attention on the database when designing domain models. Separating the domain model from the data layer may cause a certain price. you may also put the database code directly into the model (although you may use a data entry to process the actual SQL ). For relatively simple models, especially when classes and data tables are one-to-one, this method is completely feasible and can reduce coordinationObjectAnd the external system created by the database.

The above introduces the transaction script and domain model at the business logic layer, including some content, and hope to be helpful to friends who are interested in PHP tutorials.