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.
Because this is an article about software design technology, in order to make more people understand it as much 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 possible not to use these technical platforms, but the effect may not be so good. There are many platforms that support hierarchical technology, including the mainstream J2EE and. NET. Different vendors have different requirements on development platforms. The cost of a multi-layer architecture implemented using the layered technology is much higher than that of a 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 the benefits it can bring. 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. But 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. In addition, if the structure design is good enough, it can 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. This processing method spans three layers, but 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 layer-3 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 a general hierarchy 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. The Analysis Model Book fully elaborated on such objects. This layer is generally called a cross-domain layer or a 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 it is not easy to implement. 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 is very troublesome to understand this point. 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, such as the attributes and variables of the class. 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, which is the reason. 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 can greatly improve the 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. Here there are two options: one is to move forward and the other is to 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. The database implements the persistent state and submits the status 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 call method 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, rather than the specific implementation of the Target layer. 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 often many objects and methods in the business layer, and the relationship between them is also very responsible, but for other layers, 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 mode 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 address codes of different machines are 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 support for this technology. 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 objects. 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 on data from the backend will increase 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, some platform mechanisms are often used. 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. In this case, it is costly to create an object that supports transactions. 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 class 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, only the update and delete methods require transaction support. 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 and call another class in other cases. 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 facade mode in the design mode book) to encapsulate the specific implementation, and only provide users with the user's concerns. 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, the successful iteration results are very obvious. It can play a stable architecture in the next development cycle, reduce the amount of code, and improve the efficiency of software quality. Note: Do not make trendy technologies the driving force of layered iteration. This is a common problem for developers. It is not a weakness and 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, the technical director in the team must have a 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, entity beans are responsible for implementing business objects. Therefore, an application usually has a large number of entity beans. Users do not need to understand every entity Bean. For them, they only need to be able to have full business logic, but they need to deal with multiple entity beans to complete these business logic. Therefore, EJB provides session beans to encapsulate entity beans. Users only know the Session Bean and the existence of entity beans. 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 Fowler pointed out in his analysis model that the problem should be analyzed 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, rather than how the analysis object should do it. The former belongs to the analysis phase, and the latter belongs to the design or even implementation phase. In the demand project, there is a player called CRC card, which is used to analyze the duties and relationships of classes. In fact, that method is to perform object-oriented design at the conceptual level. Therefore, if you want to analyze the concept, you need to look at how a program represents a concept in the real world from the perspective of a domain expert. 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 a base class) without worrying about the implementation of a specific interface (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 an implementation method called Internal 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 the Matrin Fowler 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 some requirements are highly variable, defining interfaces is also a solution. 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, inheritance, and polymorphism. the theories of relational data models are completely different. The basic principles of object-oriented design are the three paradigms of databases. The most obvious example is that the Order object includes a group of OrderItem objects, therefore, we need to design a container in the Order class (each programming language provides a set of container objects and related operations for use) to store OrderItem, that is to say, the pointer in the Order class points to OrderItem. Suppose 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, 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.
(To be continued)
Author profile:
Lin Xing, Senior Project Manager of the Project Management Group of Chen Xun software studio, has many years of project implementation experience. Chen Xun software studio is committed to the application of advanced software ideas and software technology. Its main research direction is software process ideas, Linux cluster technology, OO technology and software factory model. You can contact him by email iamlinx@21cn.com.
