Agile thinking: Methodology in Architecture Design (10)-hierarchy (bottom)

Introduction:In the previous article, we used a lot of space to observe a practical example. I believe you have a more specific concept for layering. In this article, we will discuss the issues that may be encountered by layering in practice. Layering is a very common but not easy to use technology in architecture design. So we have spent a lot of effort here to discuss it.

This is an article about software design technology.ArticleIn order to make more people understand it as much as possible, as far as possible, it should not involve too specific technologies or platforms. However, this goal may be difficult to achieve, because the software design cannot be separated from the specific implementation technology. Therefore, what we can do in this article is not to involve specific coding details as much as possible.

When will the stratified technology be used?

The layering technology actually complicate the technology. Unlike systems with simple CS structures in the past, layering often requires specific technical platforms. Of course, it is also possible not to use these technical platforms,
However, the effect may not be that good. There are many platforms that support hierarchical technology, including the mainstream J2EE and. net. Different vendors have different requirements on development platforms. Use hierarchical Technology
The current multi-tier architecture costs much higher than the common CS architecture.

This leads to a very practical problem-not all software is suitable for Stratified technology. In general, it doesn't make much sense for small software to use Tiering, because the cost caused by Tiering exceeds its
Benefits. In the general CS structure, interface control, logical processing, and database access can be put together. This design method is simply cool in the eyes of a purely multi-layered organization. However
For small software, this is not a big deal. Because the entire set of functions from the presentation layer to the data layer are included in a function block, it can also achieve better encapsulation. Moreover, if the structure is fully designed
Good enough to avoid excessive coupling between the presentation layer, business layer, and data layer. Therefore, there is no need to use the layered technology unless necessary.

Especially when dealing with some special projects, it is not ideal to strictly distinguish the three-layer structure. For example, some database-sensitive controls are often used to quickly develop Windows interface applications.
The processing method spans three layers, but it is very practical and cost-effective. For example, some frameworks provide a comprehensive solution from the interface layer to the database, similar to Windows applications, strict three-tier
Technology is not applicable to this situation.

How to Use the layered technology?

In a sense, a layer is actually a coarse-grained component. Just as we use the component technology to divide the system, a great role of the layer is also true. The purpose is to make the system easier to understand, and different parts can be easily replaced.

The basis for Stratified technology is the actual needs of software developers. If you are using some excellent object-oriented software development platforms, they generally recommend (or force) you to use a layered mechanism. This is a big reference for using the layered technology.

For most software teams with some experience, they generally accumulate some software development experience. It contains many basic classes or components used in certain fields. These elements constitute
The general level of the system. This layer also needs to be considered during layering. For example, some common currency objects or organization objects used in some applications. Analysis Mode 1
The book fully elaborated on such objects. This layer is generally called cross-domain
Or utility layer ).

Currently, many software applications use database ing technology. The database ing layer is very important for enterprise application systems, so it must be considered. Database ing technology is easy to use, but must be implemented
Not easy. If not necessary, try to use a ready-made framework or adopt some of the design ideas. It is very expensive to try to build a large and comprehensive ing layer.
It brings a lot of trouble. The knowledge of database ing technology will be discussed in the following special sections.

How to store data (Status )?

In the process of learning EJB, the first thing to understand is the concept of stateful and stateless. It can be said that the entire concept is the core of a multi-layer system. Why? The status here refers to the status of the class,
For example, class attributes and variables. Classes vary depending on the status. For multi-layer software, the overhead of creating and destroying a class is very high, especially if the software supports distributed architecture.
Therefore, if the system is frequently called between different levels-create a class and then destroy a class. This method consumes a lot of resources. In the design of the application system, COM is generally not used separately.
Because. So we naturally think of a classic design-buffer pool. Store the object in the buffer pool. When necessary, retrieve one from the pool and put the object into the pool when not needed. This design concept
It can greatly improve efficiency. However, this imposes demanding requirements on objects that can be placed in the pool-all objects must be stateless. Only in this way can the buffer pool be implemented.

In general, the object buffer pool technology is used on the intermediate business layer. Since the intermediate service layer cannot be retained in a state, a state transfer problem occurs. There are two options:
Forward, move the status to the client, the most typical is to use cookies. This option is generally because the status is related to the user end and does not need to be saved for a long time. Another option is to move the status to the data layer
Database to realize the persistent state, and submit the state to the business layer only when necessary. This method is the most widely used in enterprise application software, but it also increases the burden on the database.

Processed Interfaces

Because of the layered technology, it is necessary to re-evaluate the complex relationship between classes in the CS structure. Generally, the coupling between layers should not be too large. Therefore, we need to carefully design the class adjustment between layers.
. Some distributed software systems (such as J2EE) provide requirements for calling methods between layers in the form of interfaces. At the same time, different layers only know the interface of the Target layer, but do not know the specific implementation of the Target layer.
Now. This is the case with the home interface and remote interface of EJB. In the COM + system, you also need to publish the interface while designing the class for the customer to use.

When designing an interface between layers, developers must consider the constraints of the development platform. That is, the business needs. There are usually many objects and methods in the business layer.
The relationship is also very responsible, but for other levels, it does not care about these details. Therefore, the interfaces published at the business layer must be simple and independent from the implementation. Therefore, you can use the design mode facade.
To simplify the interface between layers. This method is very effective, and the difference between sessionbean and entitybean in EJB contains this design idea.

Similarly, data transmission between different layers also has problems. If the physical nodes on different layers are working together, if they are not working together, distributed technology should be used. Because the memory addresses of different machines
The encoding is different. If the interface is referenced by an object, the problem may occur. Therefore, the object will be packaged into a string, sent to the target machine, and then restored to the object. All distributed Platforms provide
We will not talk about the support for this technology here. However, this implementation technology will have an impact on our design ideas. A small amount of data is directly transmitted using strings. If there is a large amount of data, we need to use encapsulated data.
. The design of such objects requires caution. You can refer to some standard practices provided by the development platform during the design process. Similarly, the frequency of data requests is also one of the difficulties. Too frequent operations come from
The data at the end will increase the system overhead. Therefore, we also need to consider the actual application when designing the call method.

Balance efficiency

Generally, the software designed by purely object-oriented designers is perfect. However, you must pay a certain price. When programming on some big software platforms, we often need to use some machines on the platform.
. The most typical is the platform's transaction mechanism (the most typical includes the JTs of the J2EE platform and the MTS of the COM + platform). However, the implementation of the Transaction Mechanism often requires the support of a large number of objects on the platform. This
The overhead of creating an object that supports transactions is high. There is a work und to solve this problem, that is, to only provide transaction support for objects that require transaction support. This means that a separate business
Entity classes may need to be divided into two types based on whether or not transactions are supported: The select method for the business entity does not require transaction support, and only the update and delete methods need transaction support
Hold. This is not in line with the idea of object-oriented designers. However, this approach can achieve excellent efficiency.

Figure 1 Separate a single business entity into different implementations
 

It should be acknowledged that this approach to improve efficiency increases complexity. Because for clients, they do not care about specific implementation technologies. The client is required to call this class in one case. In other cases
Another class is called. This method does not conform to the object-oriented design idea, but also increases the Coupling Degree and complexity between layers. Therefore, we can consider using interfaces or appearance classes (see the Design Patterns
Facade mode), encapsulate the specific implementation, and only provide the part of the user's interest to the user. This technique is also described in the following sections.

Layer by Iteration

Iteration practices in software design can also be applied to layers. According to your own experience, it is difficult to define all layers at the beginning. Unless there is a wealth of experience, there is always a big or small gap between implementation and the original design. Therefore, adjustments are imperative. Each iteration can improve the layered technology and accumulate experience for the next project.

The hierarchical iterations here cannot be too frequent. Each iteration is a major change to the architecture, which requires manpower input and affects the progress of software development. However, successful iterations are very effective.
Obviously, stable architecture can be implemented in the next development cycle to reduceCodeTo improve the software quality. Note: Do not make trendy technologies the driving force of layered iteration. This is what developers often do.
This is not a weakness. It can only be called an occupational disease. The driving force of layered iteration should be derived from the evolution of demand and the instability of the existing architecture, which has hindered further software development. Therefore, this requires the team
The Technical Director has a very good grasp of the technology.

Refactoring can be helpful for iteration. Sniff out and improve the hidden bad taste in the code. It should be said that iteration is a fierce approach, and a better approach is to constantly adjust the architecture and layers during development. However, this imposes high requirements on teams, technologies, methods, and processes. Therefore, iteration is still a major improvement method.

Layer subdivision

The idea of layering can also be applied to the interior of layers. There is no fixed way to segment the layer, and its driving factors are usually out of encapsulation and reuse considerations. For example, in the business layer of the EJB system, the entity
Bean is responsible for implementing business objects. Therefore, an application usually has a large number of entity beans. The user end does not need to understand every entity bean. For them, as long as they can completely implement some business logic
But to complete these business logic, you need to deal with multiple entity beans. Therefore, EJB provides session beans to encapsulate entity beans. Users only know session beans,
The existence of the Entity Bean is unknown. This not only ensures the reusability of the Entity Bean, but also achieves encapsulation well.

Interface-Oriented Programming

In the previous section, we mentioned an interface design example. Why do we advocate interface design? Martin
In his analysis model, Fowler pointed out that the analysis problem should be at the conceptual level, rather than at the implementation level. What is the level of concept? Simply put, it is what the analysis object should do,
Instead of the analysis object. The former belongs to the analysis phase, and the latter belongs to the design or even implementation phase. In the demand project, a player called CRC card is used to analyze the duties and relationships of classes.
The actual method is to implement object-oriented design at the conceptual level. Therefore, if you want to analyze the concept, you need to look at it from the perspective of domain experts.ProgramHow to express concepts in the real world.
In the following sentence, there are some technical points. From the implementation perspective, the conceptual level corresponds to the contract, and the contract implementation forms include interfaces and basic classes. To put it simply, analyzing at the conceptual level is to design an interface (or
Class), instead of concerning the implementation of specific interfaces (implementation is postponed until the subclass is implemented ). Based on the above discussion, we can also infer that the interface should be in line with the concept of the real world.

Another article by Martin Fowler mentioned this example, which explains the idea of Interface Programming very well:

Interface person { Public string name (); Public void name (string newname ); Public money salary (); Public void salary (money newsalary ); Public money payamount (); Public void makemanager (); } Interface engineer extends person { Public void numberofpatents (INT value ); Public int numberofpatents (); } Interface salesman extends person { Public void numberofsales (INT numberofsales ); Public int numberofsales (); } Interface manager extends person { Public void budget (money value ); Public money Budget (); }

As you can see, in order to express the concept of people in the real world (this actually refers to the concept of employees), engineers, salespeople, and managers, the code designs an inheritance hierarchy based on the natural viewpoint of people, and can be reused. In addition, we can determine that this interface is relatively stable. Let's take a look at the implementation section:

Public class personimpflag implements person, salesman, engineer, Manager { // Implementing salesman Public static salesman newsalesman (string name ){ Personimpflag result; Result = new personimpflag (name ); Result. makesalesman (); Return result; }; Public void makesalesman (){ _ Jobtitle = 1; }; Public Boolean issalesman (){ Return _ jobtitle = 1; }; Public void numberofsales (INT value ){ Requireissalesman (); _ Numberofsales = value; }; Public int numberofsales (){ Requireissalesman (); Return _ numberofsales; }; Private void requireissalesman (){ If (! Issalesman () throw new preconditionviolation ("not a salesman "); }; Private int _ numberofsales; Private int _ jobtitle; }

This is one of
Flag. Here we just give an example. In fact, we still have a lot of solutions, but we don't care about them. As long as the interface is stable enough, any major changes to the internal implementation are allowed. If you are interested in the implementation method, refer to matrin
Fowler's role modeling article or a note I am reading this article.

Through the above example, we can understand that the biggest benefit of interface and implementation separation is the ability to modify the implementation code when the client is unknown. This feature is very suitable for layered technology. One is
Used for calling between layers. Between layers is the most taboo coupling is too high or the change is too frequent. Well-designed interfaces can solve this problem. The other is used for unstable parts. If you need
Therefore, defining interfaces is also a solution to this problem. For example, a well-designed interface is like a universal socket that we use everyday. It can be used no matter how the plug changes.

Finally, it is emphasized that a good interface definition must come from the needs, and it is definitely not produced by programmers.

Data ing Layer

The data ing layer may be confusing in the design of each layer. Due to the length of the article, we cannot discuss too much on this issue. If you have the opportunity, we can also talk about this topic.

Object-oriented technology has become a trend in software development. More and more people begin to understand, learn, and use object-oriented technology. Most object-oriented technologies only solve the problem of object-oriented in memory. However, persistent object-oriented issues are rarely mentioned.

The mechanism of object-oriented design is very different from the relational model, which leads to mismatch between object-oriented design and relational database design. The basic theories of object-oriented design include coupling, aggregation, encapsulation
The theory of relational data models is completely different. The basic principle of relational data models is the three major paradigms of databases. The most obvious example is that the Order object includes a group of orderitem objects, because
Therefore, we need to design a container in the order class (eachProgramming LanguageA group of container objects and related operations are provided for use .)
The Pointer Points to orderitem. Assume that the Order class and orderitem correspond to the two tables in the database respectively (the simplest ing condition). Then, we need to implement the relationship between the two, which is
Add a foreign key pointing to the order table in the orderitem table (assuming the same name. These are two completely different settings. The data ing layer is used to hide the existence of a relational database on the user end.

Developing an object/link ing tool by yourself is very attractive. However, it should be considered that developing such a tool is not easy and requires a great deal of cost. Especially for manual data consistency and transaction processing. It is much harder than you think. Therefore, the best way to obtain an object/link ing tool is to purchase, rather than develop.

Summary

Hierarchy is a very important concept for modern software development. This is what we must learn. There is nothing special about the overall idea of layering, but you still need to make a lot of effort to combine it with your own development environment and application environment.

After the layers are completed, the software architecture has actually been clarified. The following discussion will focus on how to improve the architecture and how to make the architecture stable.