Enterprise Application Architecture Model Reading Notes (1)

This article from: http://www.cnblogs.com/yuyijq/archive/2010/03/13/1684938.html

 

 

Martin Fowler, the enterprise application architecture model, should have been a household name. After buying it for a few days, he never picked it up. Now he has finally reached this book.

This book is roughly divided into two parts. The first eight chapters are the first part, which gives a preliminary introduction to enterprise-level development, then, the application scenarios and advantages and disadvantages of some models are briefly explained. The second part is the list of models. The classification of these models is based on the considerations for enterprise-level development described in the first part. Now I only read the first part.

What is enterprise-level development?

In the introduction chapter, Martin's statement about "enterprise application" is very interesting: Many people think that "Enterprise Applications" are big systems, but in fact not all enterprise applications are big, even if they provide a lot of value to the Enterprise.

Martin's reason is that enterprise-level applications focus on the business logic of the field. This business logic is very complex, but less on the large throughput and high concurrency of systems such as the telecommunications industry.

Martin said: "enterprise applications often have complex data-And lots of it-to work on, together with business rules that fail all tests of logical reasoning ."

According to the characteristics of enterprise-level applications, Martin has summarized some common features:

Persistent data:Generally, enterprise-level applications need to persist data (but this seems to be the case for most systems today)

A lot of data:A large amount of data may be a little dumb compared to today's Web 2.0 websites, but it depends on what industry

Access Data concurrently:I don't feel much about concurrent access to data. I am engaged in software development in the oil industry. Even if users are online at the same time, I am not talking about high concurrency.

Transaction:This is true. Generally, enterprise applications are closely related to money, and transaction processing seems very common (personal feeling)

A lot of user interface screens:Many user interfaces. This is also a system-intensive interface, but some people say that there are more Web 2.0 application interfaces today, that is massive. However, Web 2.0 has many website interfaces, but most of them are the same, but the data is different. enterprise-level applications have a bunch of different interfaces.

Low user technical level:This is my heart. Enterprise applications generally face people in other fields. They think a lot differently from our IT staff. This is a very troublesome thing.

Integrate with other enterprise applications:Integration with other systems. Let alone it. I am still worried about it. Now I am doing something integrated. If all the systems are developed by one of us, we can say that the technologies developed and used by various companies are also strange. In this case, it is a pain point for all systems.

Although many features have been cited above, only a few of them are touched by the complexity of the business logic, I think the biggest difficulty for enterprise-level applications is that a group of IT staff should deal with a group of users in other industries. I remember taking me to the site as the first person at work, the customer talked about the hype. I was like a dumb. I couldn't understand the oil recovery and the distribution of the remaining oil. I bought several petroleum books and read them by myself. Another feeling is that enterprise-level applications are lagging behind in technology and everything is safe. In terms of scalability, enterprises can purchase hardware with better performance to solve some bottlenecks. There are few ways to scale horizontally, so I am very depressed and cannot try some very popular architectures (such as the key/value database and Data Partition articles written by Lao Zhao recentlyArticle).

Layered

In the first chapter of this book, we talk about layering and clarify some concepts: the difference between layer and tier. Layer generally refers to logical layers, such as UI, BLL, and Dal. Tier refers to physical layering. Generally, as developers, we focus more on logical layering, that is, layer.

The classic and damn three-tier architecture is still indispensable here. A table is listed here:

Layered	Responsibilities
Presentation Layer	Provides services and displays information (for example, processing user requests and HTTP requests in windows and HTML ).
Domain Layer	Logic, the true core of the system
Data Access	Communication with databases, message systems, transaction managers, and other systems (not just operating databases)

There is nothing to say here, that is, the domain layer. Before I started my work, all I did was web, and most of it was news or forums. At that time, I looked at this layer-3 architecture every day. Why are there multiple business logic layers? There is no logic, but to "prove" that I am using a layer-3 architecture, I also added a business logic layer, but in fact that layer is only a proxy, and the method called from the interface is passed directly to the data access layer. The second layer is enough. At that time, we didn't actually understand the significance of the layer. Instead, we should not layer the layer for the purpose of dividing the responsibilities between the layer and the boundaries of the layer, suppress changes in the layer, and do not spread between layers. If it is as simple as two layers, two layers are needed.

But the work is different. The current system, writeCodeThe most important part is the business logic layer, so the responsibility of this layer is also reflected.

Here, Martin also teaches a method to determine what should be put on the business logic layer and what is the interface logic:

Add an identical layer. For example, if you want to create a web application and you already have a presentation layer, you can also add a presentation layer. This time, you can use the console to implement the presentation layer, let's take a look at the repeated code between the HTML display layer and the console display layer, and transfer the repeated code to the business logic layer.

Haha, this method may not be useful to you. It is really good for me. It seems that we have been doing this all the time. Most of our systems are developed for B/S and C/S, so .....

Organize business logic

Chapter 2 describes how to organize business logic. Martin summarized three main models: Transaction script, domain model, and table module.

In fact, these three models correspond to process-oriented, object-oriented, and database-oriented. Marvel at Martin's dummies.

Transaction script? What is a transaction script? In fact, you often create an SQL statement, make a query, and return a result. This process is used.
The domain model is to create several classes according to their responsibilities. Each class is only responsible for its own responsibilities, and objects are organically organized together.
The table module is actually a class for each table. It is a singleton class that is responsible for table-related operations.

I didn't use the third party very much. For the first two, many people conflict with the transaction script in terms of consciousness. This is the product of the process. But in fact, for some simple applications, such as reports, the business logic is very simple, direct, not always changed, the transaction script is excellent, you still have a few objects tired.

However, when the business logic is a bit uncertain, for example, there is a code that decides what operations to execute based on the type of things, you should not create a bunch of if else or switch, let's get an object level to process this. However, when creating a domain model, you must first think about the responsibilities and the owner of all objects.

Map to Relational Database

Chapter 3 maps to relational databases, which is a big topic. This chapter is also very detailed and describes many problems in actual development.

Before speaking about Martin, let me talk about the following issues:

1. To support a variety of databases, this is a good project. To achieve this, products require support for Oracle, SQL Server, and sysbase, and sometimes support access for standalone applications. Even for the same database, different versions are also supported. For example, once the system was implemented in an oilfield, the old connection of the system could not be reached, and there was no way to debug it on site, finally, we found out whether they used the database or Oracle 6, and we used Oracle 10 Gb for product development. Fortunately, we used ibatis. net, change it to OK.

2. The database has been finalized. I believe that many enterprises have encountered this problem. It is designed for legacy databases. There is a lot of historical data in it and it is impossible for you to design it again, what is particularly depressing is that some data tables are designed improperly and cannot be changed. One time I met a table, I could actually divide it into three tables, but they were all placed in one table to form a "flat" structure. I was puzzled, is it because the data in this table is usually collected by sensors and then stored by a dedicated device, the flat structure of the embedded device is better, my God.

3. Offline applications. This is also highly demanded by many users. If a computer is carried back to the leader to report the demonstration, PPT is used in the past, and the leader cannot read other data, now that you have the software, you can use it to demonstrate it directly. However, it is difficult for the leaders to pull out the network cable, or they cannot connect to the internal network of the enterprise on a business trip, well, this is also a headache.

This is a problem that I often encounter. Let's summarize it.

Martin has a lot of discussions on ing to relational databases, and I also think that ing to relational databases is also a major issue in daily development. So in this article, Let's go here, in the next article, I will talk about some precautions.

Digress

It is a waste to buy a book without reading it. This book has been bought for more than a year and is still the same as a new one. I really realized who said the sentence. What is missing now is not a book, but a reader.

 

Martin Fowler, the enterprise application architecture model, should have been a household name. After buying it for a few days, he never picked it up. Now he has finally reached this book.

This book is roughly divided into two parts. The first eight chapters are the first part, which gives a preliminary introduction to enterprise-level development, then, the application scenarios and advantages and disadvantages of some models are briefly explained. The second part is the list of models. The classification of these models is based on the considerations for enterprise-level development described in the first part. Now I only read the first part.

What is enterprise-level development?

In the introduction chapter, Martin's statement about "enterprise application" is very interesting: Many people think that "Enterprise Applications" are big systems, but in fact not all enterprise applications are big, even if they provide a lot of value to the Enterprise.

Martin's reason is that enterprise-level applications focus on the business logic of the field. This business logic is very complex, but less on the large throughput and high concurrency of systems such as the telecommunications industry.

Martin said: "enterprise applications often have complex data-And lots of it-to work on, together with business rules that fail all tests of logical reasoning ."

According to the characteristics of enterprise-level applications, Martin has summarized some common features:

Persistent data:Generally, enterprise-level applications need to persist data (but this seems to be the case for most systems today)

A lot of data:A large amount of data may be a little dumb compared to today's Web 2.0 websites, but it depends on what industry

Access Data concurrently:I don't feel much about concurrent access to data. I am engaged in software development in the oil industry. Even if users are online at the same time, I am not talking about high concurrency.

Transaction:This is true. Generally, enterprise applications are closely related to money, and transaction processing seems very common (personal feeling)

A lot of user interface screens:Many user interfaces. This is also a system-intensive interface, but some people say that there are more Web 2.0 application interfaces today, that is massive. However, Web 2.0 has many website interfaces, but most of them are the same, but the data is different. enterprise-level applications have a bunch of different interfaces.

Low user technical level:This is my heart. Enterprise applications generally face people in other fields. They think a lot differently from our IT staff. This is a very troublesome thing.

Integrate with other enterprise applications:Integration with other systems. Let alone it. I am still worried about it. Now I am doing something integrated. If all the systems are developed by one of us, we can say that the technologies developed and used by various companies are also strange. In this case, it is a pain point for all systems.

Although many features have been cited above, only a few of them are touched by the complexity of the business logic, I think the biggest difficulty for enterprise-level applications is that a group of IT staff should deal with a group of users in other industries. I remember taking me to the site as the first person at work, the customer talked about the hype. I was like a dumb. I couldn't understand the oil recovery and the distribution of the remaining oil. I bought several petroleum books and read them by myself. Another feeling is that enterprise-level applications are lagging behind in technology and everything is safe. In terms of scalability, enterprises can purchase hardware with better performance to solve some bottlenecks. There are few ways to scale horizontally, so I am very depressed and cannot try some very popular architectures (for example, some articles about key/value databases and data partitions recently written by Lao Zhao ).

Layered

In the first chapter of this book, we talk about layering and clarify some concepts: the difference between layer and tier. Layer generally refers to logical layers, such as UI, BLL, and Dal. Tier refers to physical layering. Generally, as developers, we focus more on logical layering, that is, layer.

The classic and damn three-tier architecture is still indispensable here. A table is listed here:

Layered	Responsibilities
Presentation Layer	Provides services and displays information (for example, processing user requests and HTTP requests in windows and HTML ).
Domain Layer	Logic, the true core of the system
Data Access	Communication with databases, message systems, transaction managers, and other systems (not just operating databases)

There is nothing to say here, that is, the domain layer. Before I started my work, all I did was web, and most of it was news or forums. At that time, I looked at this layer-3 architecture every day. Why are there multiple business logic layers? There is no logic, but to "prove" that I am using a layer-3 architecture, I also added a business logic layer, but in fact that layer is only a proxy, and the method called from the interface is passed directly to the data access layer. The second layer is enough. At that time, we didn't actually understand the significance of the layer. Instead, we should not layer the layer for the purpose of dividing the responsibilities between the layer and the boundaries of the layer, suppress changes in the layer, and do not spread between layers. If it is as simple as two layers, two layers are needed.

But the work is different. The business logic layer is the most frequently written part of the current system, so the responsibilities of this layer are also reflected.

Here, Martin also teaches a method to determine what should be put on the business logic layer and what is the interface logic:

Add an identical layer. For example, if you want to create a web application and you already have a presentation layer, you can also add a presentation layer. This time, you can use the console to implement the presentation layer, let's take a look at the repeated code between the HTML display layer and the console display layer, and transfer the repeated code to the business logic layer.

Haha, this method may not be useful to you. It is really good for me. It seems that we have been doing this all the time. Most of our systems are developed for B/S and C/S, so .....

Organize business logic

Chapter 2 describes how to organize business logic. Martin summarized three main models: Transaction script, domain model, and table module.

In fact, these three models correspond to process-oriented, object-oriented, and database-oriented. Marvel at Martin's dummies.

Transaction script? What is a transaction script? In fact, you often create an SQL statement, make a query, and return a result. This process is used.
The domain model is to create several classes according to their responsibilities. Each class is only responsible for its own responsibilities, and objects are organically organized together.
The table module is actually a class for each table. It is a singleton class that is responsible for table-related operations.

I didn't use the third party very much. For the first two, many people conflict with the transaction script in terms of consciousness. This is the product of the process. But in fact, for some simple applications, such as reports, the business logic is very simple, direct, not always changed, the transaction script is excellent, you still have a few objects tired.

However, when the business logic is a bit uncertain, for example, there is a code that decides what operations to execute based on the type of things, you should not create a bunch of if else or switch, let's get an object level to process this. However, when creating a domain model, you must first think about the responsibilities and the owner of all objects.

Map to Relational Database

Chapter 3 maps to relational databases, which is a big topic. This chapter is also very detailed and describes many problems in actual development.

Before speaking about Martin, let me talk about the following issues:

1. To support a variety of databases, this is a good project. To achieve this, products require support for Oracle, SQL Server, and sysbase, and sometimes support access for standalone applications. Even for the same database, different versions are also supported. For example, once the system was implemented in an oilfield, the old connection of the system could not be reached, and there was no way to debug it on site, finally, we found out whether they used the database or Oracle 6, and we used Oracle 10 Gb for product development. Fortunately, we used ibatis. net, change it to OK.

2. The database has been finalized. I believe that many enterprises have encountered this problem. It is designed for legacy databases. There is a lot of historical data in it and it is impossible for you to design it again, what is particularly depressing is that some data tables are designed improperly and cannot be changed. One time I met a table, I could actually divide it into three tables, but they were all placed in one table to form a "flat" structure. I was puzzled, is it because the data in this table is usually collected by sensors and then stored by a dedicated device, the flat structure of the embedded device is better, my God.

3. Offline applications. This is also highly demanded by many users. If a computer is carried back to the leader to report the demonstration, PPT is used in the past, and the leader cannot read other data, now that you have the software, you can use it to demonstrate it directly. However, it is difficult for the leaders to pull out the network cable, or they cannot connect to the internal network of the enterprise on a business trip, well, this is also a headache.

This is a problem that I often encounter. Let's summarize it.

Martin has a lot of discussions on ing to relational databases, and I also think that ing to relational databases is also a major issue in daily development. So in this article, Let's go here, in the next article, I will talk about some precautions.

Digress

It is a waste to buy a book without reading it. This book has been bought for more than a year and is still the same as a new one. I really realized who said the sentence. What is missing now is not a book, but a reader.