Nine - layered (on)
After defining the architectural vision, all people in the team should have a certain understanding of the software to be developed. However, in the face of a huge software system, what do you want to do next? The idea of separation is that we are very important in the computer field, so we will start from here.
To make the design of the application, the layering is very important, mastering the hierarchical idea, the design of the software can be pleasing. Due to the importance and specialties of this chapter, the contents of this chapter are divided into two sections, and the mode description language is not taken.
The hierarchical is just a way to organize the system.
This chapter is specifically discussed for enterprise applications, but most of them can be applied in other systems or other systems.
In corporate applications, there are two very important concepts: business logic and persistence. It can be said that enterprise applications are carried out around business logic. For example, reimbursement, order, goods storage, etc. are both business logic. From the underlying implementation of business logic, business logic is actually an organization that organizes business entities. This is true for object-oriented systems, because in an object-oriented system, identify business entities, and develop a business entity behavior, and different business entities have formed business logic.
Another important concept is persistence. Most of the data in enterprise applications requires sustainable. Therefore, the basic organization supports persistence and is very important. The most popular support for persistence is the database, especially the relationship database - RDBMS.
In addition, there are other important concepts in enterprise applications, such as human-computer interaction.
In order to be able to organize more logic in the enterprise, we use layer technology to realize enterprise applications. The layer technology has a long history in the computer field, and the concept of layering is referenced in the implementation of the computer. The seven-layer protocol stack of TCP / IP is also a typical hierarchical concept. The stratification advantage is:
The upper layer logic does not need to understand all underlying logic, it only needs to understand the details of the layer adjacent to it. We know that the TCP / IP protocol stack is a layered packet through different layers, and the coupling degree between different layers is significantly reduced. By strict distinguishing level, the coupling degree between the layers is greatly reduced.
A certain level of subtracks can have different implementations. For example, the same programming language can be run in different operating systems and different machines.
Similar to the third, the same level can support different superiors. The TCP protocol can support an application layer protocol such as FTP, HTTP.
In order to consider it, we divide enterprise applications into multiple levels. The company should be divided into several levels, and there is no unified comment.
In the software development of the previous year, two layers of structures have a very important location. For example, a wide range of large host / terminal methods are applied in the bank, as well as the Client / Server mode. The two-story architecture has been widely existent, but the two layers have a lot of disadvantages, such as high maintenance costs, difficult to achieve distributed processing. As the terminal user and the backend service between the two-layer structure, the multilayer structure appears.
The classic three-layer theory will be divided into three levels:
◆ Presentation Layer for handling human machine interaction. The two most mainstream representations are Windows formats and WebBrowser formats. Its main responsibility is to process user requests, such as mouse click, input, http request, etc.
◆ Domain logic layer, simulating the actual activities in the enterprise, or it is also a model of enterprise activities.
◆ Data Source Layer, Processing Database, Message System, Transaction System.
In practical applications, the three-layer structure has some changes. For example, in the .NET system in Windows, the application is divided into three hierarchies, the business layer, the data access layer (Data Access Layer), respectively corresponds to the classic three-layer theory. Three levels. It is worth mentioning that the .NET system indicates that the layer can directly access the data access layer, that is, the recording set technology. In ADO.NET, this technology has been very mature and a very friendly function is achieved by representing certain data perceived components in the layer. This kind of leaving access is generally considered to be not allowed because it may damage the dependencies between the layers. In the Windows platform, strict compliance with guidelines means that there is a lot of extra workload. Therefore, we see guidelines are not unchanged. In J2EE's environment, the three-layer structure evolved into a five-layer structure. In the representation of the layer, J2EE divides it into a client layer running on the client, as well as the Web layer that runs on the server. The main reason for doing this is that web server has become a very core technique in J2EE, such as JSP and Java Servlets and it has it. The Web layer provides a logic to the user layer and responds to the user's request.
Business Layer has not changed and is still the processing application core logic. The data layer is divided into two levels: Integration Layer and Resource Layer. Among them, the resource layer does not care about J2EE, which may be a database or other old system, an integrated layer is an important level, including transaction, database mapping system.
Example
The organizational mode of this chapter has some differences. We first experience the importance of layering in architectural design from an example.
The above figure is a software architecture diagram of a business processing system. In the figure above, we divide the software into four levels. This hierarchy is similar to the layering of J2EE mentioned earlier. But different from J2EE is that there is a WEB Server layer because we currently have no need to Web Server.
On the resource layer, we have three resources: database, platform service, and ui. The database is the foundation of enterprise applications, and the platform service here is the functionality of the operating manager provided by the operating system or third-party software. It is worth noting that the transaction manager here is not the transaction supported by the database, but refers to different business entity transaction processing, which is very important for corporate applications. Because for an enterprise application, often need to process across modules, cross-software, and even cross-platform sessions (SESSION), this time, transactions supported by simple databases often are difficult to compete. Examples of this include Microsoft's MTS and Oracle DBLINK. Of course, if you say, in your system, you can use database transactions to handle most of the sessions, you can avoid consideration of this design. In addition to a typical transaction manager, the platform can also provide other services. For most enterprise applications, it is integrated with multiple platform services, and platform services are critical to architectural design. However, from a hierarchical point of view, the design of the upper layer should be as not related to the platform as possible. Similar to the platform service, in general, corporate applications will not use existing UI resources from the head design interface, most of them. For example, the interface part of the MFC of the Window platform. Therefore, we will return the UI resources used to the resource layer. The last layer of the resource layer is an integrated layer. The integrated layer mainly completes two work, the first is the platform service using the resource layer to complete transaction management in enterprise applications. Some transaction mechanisms have provided a better package mechanism that directly using the platform service of the resource layer. But for most applications, the services provided by the platform are often relatively simple. At this time, the integrated layer will send a big use. The second is to provide a persistence mechanism for the object of the previous layer. It can be said that this is a group of objects that play a transition role. It actually uses the database function of the resource layer and serves the previous layer of objects. In this way, the business object of the last layer does not need to be dealt with the database. For those underlying relational databases, the use of object-oriented technology is used in the programming, and the current relatively common processes are object / relational mappings.
At this level, we can do some extensions to analyze the role of the layer. Suppose our system needs to handle multiple databases, while the processing mode between different databases has a certain difference. At this time, the role of the layer is displayed. We support the processing of multiple databases in the integrated layer, but provide a unified interface for hierarchies above the integrated layer. For business layers, it doesn't know that it is not necessary to know the difference in the database. At present, we have developed a long-lasting class in the integrated layer, but with the expansion of the function, the original classes cannot support newly added features, and the new solution is to buy commercial programs. In order to maintain the impact on the business level, we still use the original interface, but the specific implementation has been different, and the new code is implemented for new business programs. For business layers, the most ideal situation does not require any changes. Of course, this is unlikely to have such a better situation, but it is certain that the introduction level is much better than the incoming level.
The two examples listed above are well solved the problem of coupling. With regard to the problem of coupling in layers, we will also discuss below.
The design of the business layer is relatively simple, temporarily just implemented it as a set of business classes. Similarly, there is no more processing in the design of the layer. The class representing the layer is inheriting from the resource layer. This is a method of processing. Of course, it can be used, which is related to the specific implementation of the environment and designer's preferences. It is not the only approach. After a preliminary understanding of the process of software, we need further excavation of demand to refine our design. In the previous design, our design of the business layer is too rough. In our application, there is an old system. In this system, the application rules are implemented. From the perspective of application, these rules are still in use, but new rules will be added in new systems. After the new system is enabled, the rules processing in the old system still needs to play its role, so it is not possible to simply transfer all rules to the new system. (Sometimes we save costs without the logic of old systems in the new system). The support of our second steps will be added during the refinement of architecture design. In the process of refining the business layer, we still use layer technology. At this time, we divided the original business layer into two sub-layers. For most enterprise applications, business layers are often most complicated. There is an intricate connection between enterprise objects, and the company's processes need to use these seemingly independent business objects. We hope to introduce new mechanisms in the business layer to achieve the purpose of organizing business classes. The organization of the business layer needs to rely on specific applications, and the application of the financial industry and the application of the manufacturing industry have a huge gap. Here, we will look at our design from the perspective of general design thinking:
First, we see that the business layer is reorganized to two levels. The main consideration of increased hierarchy is the reuse of the design. From our awareness of our front, we know. Higher levels can reuse lower levels. Therefore, we set a classification in the business layer to a lower level for use in higher levels. The main idea of reducing class level is to decompose behavior, identify common behavior, and draw commonness.
A method of separating an operating layer and a knowledge layer is provided in the analysis mode of Martin Fowler:
Action, Accountability, Party belong to a higher level of Operational Layer, which is characterized by specific applications. But observe Accountability and Party, there are many similar responsibilities. That is to say, we are not suitable for the treatment of knowledge. Therefore, Martin Fowler proposes a new level-belonging to a lower level of knowledge layer (Knowledge Layer). Knowledge that can be reused in the operating layer is organized to the knowledge layer. Thereby, the commonal extraction of the operating layer is achieved. It is noted that although the concept and layer of Level in the figure are different, the idea is basically consistent.
Another hierarchical method is to use inheritance:
This figure is also from the analysis mode. Different sectors have differences and commonality, and the basic concept of the inheritance of the inheritance of the inheritance. At this time, we can regard the parent class as a lower level, while the subclass is considered a higher level. For a wide range of hierarchies, the hierarchy can also be separated from a horizontal line.
The last method needs to decompose and abstract objects. The ability of the Iterator is implemented for different data types and different containers in the STL of C . Its implementation is a typical reduction of hierarchy. We don't consider its support for different data types because it uses a relatively unique template technology, just considering its implementation of different containers. The first is the analysis of commonality, whether it is array or vector, to perform traversal operation, you need to know three conditions: the starting point of the container, the length, matching value of the container. This is an abstraction. In this way, the interfaces of different containers can be unified. We discussed the benefits and implementation strategies of the fine level. Let's go back to the foresee, continue to discuss the various components in the layer.
Business entities refer to some individual objects in the enterprise. For example, orders, customers, suppliers, etc. Since the business entity can be used by a lot of business processes (business sessions), we put business entities in the business entity layer. Most business entities in the enterprise require persistence. Therefore, in our design, the business entity entrusts the persistent responsibilities to the last level of persistence bags, rather than directly calling the database method. Another common method is to use inheritance-business entities inheritance self-lasting class. ENTIN's ENTITY bean is a typical business entity that supports an automated persistence mechanism.
In our system, the rule is an embarrassing existence. Part of the rules are in the old system and use the persistence mechanism of the old system. There is a need to support new rules in the new system. For users of the upper layer, do not need to know the rules of the new and old system. If we do a new and old rules when using rules and call different system functions, it is too stupid. Our design should be transparent to the upper level.
So we have designed three packages to achieve rules. The wrapper wraps the rules in the old system so that it is in a few considerations: First, the old system is a process, so we need to encapsulate function (or procedures) into the class with a package. Second, the use of the use of the old system requires an additional program (or platform service), so a separate class is required. Finally, we can use the Adapter mode [GOF 94] to unify the interfaces of the new and old system to make them work together. The new rule class realizes new rules, and better practices are defined a virtual protocol, and the specific expression may be a virtual base class or interface. The virtual protocol is then realized by its subclasses. The rule interface can be unified in connection with the method of converting the old rule interface into a new interface. From the figure we see that business entities need rules, through unified interfaces, business entities can transparently use new and old rules.
After defining rules and standard rule interfaces, the last level of the rule controller can achieve different rules combinations by calling rules. So this rule controller is similar to the application rules. Call the rule controller in business transaction processing to implement partial functions.
Please note that the ideas discussed here is very simple, clear, but reality is not so easy. Because it is too difficult to develop a unified interface for new and old rules. It is more difficult to make the interface in the future. After the application has been deployed, any small changes to the published interface mean high costs. On this issue, there is no good strategy, and experience is the most important. A relatively practical method in the actual situation is to add some additional parameters for the interface. Even if this parameter is currently not used, but if you can use it, then add it. For example, for commercial applications, a database, or a relational database must be an indispensable part. A large number of operations need to be combined with the database, so it is possible to consider the parameters of a database connection string in the method can be considered. Although this is not necessary for many ways, it provides an expandable space for future practices. The design of a well-known ERP software in China uses this idea. The main energy of this chapter is placed in the study. After a basic concept, we will come back to talk about some of the principles of layers and what you need to pay attention.
Nine, - layered (below)
The last article we used a lot of space to observe an actual example. I believe that everyone has had a more concrete concept of layering. In this article we will discuss the problems that the layers may encounter in practice. The layering is a very common in architecture design, but it is not easy to use well. So we spent a lot of breath here to discuss it.
Since this is an article introducing software design technology, in order to make more people as much as possible, this should not involve too specific techniques or platforms as much as possible. But this goal may be difficult to implement, because software design is unable to detach the specific implementation technology. Therefore, it can be made in this article that does not involve specific coding details as much as possible.
When is hierarchical technology?
The hierarchical technology is actually complicated by technology. Different from the previous simple CS structure, layers often need to be implemented using a particular technical platform. Of course, it is also possible to use these technical platforms, but the effect may not be so good. There are many platforms that support hierarchical technology, including the current mainstream J2EE and .NET. Even on the development platform of different vendors, the requirements are different. The multi-layer architecture implemented using a layered technology is much higher than that of ordinary CS architectures.
This produces a very realistic issue - not all software is suitable for hierarchical technology. In general, small software uses hierarchical, because the cost of layering exceeds the benefits that it can bring. In a general CS structure, interface control, logic processing, and database access can be placed on one. This design method is that pure multi-layerists seem to be ten evil. But for small software, this is not a big deal. Because the entire function of the layer to the data layer is included in a functional block, a better package can also be achieved. Moreover, if the structure is well enough, it is also possible to avoid excessive coupling degrees between the layer, the business layer, and the data layer. Therefore, unless otherwise needed, it is not necessary to use layered techniques.
Especially when dealing with some special projects, strict distinguishing three-layer structure is not ideal. For example, when the application of the Windows interface is often used, some controls for database sensitive controls are often used, which spans three levels, but it is very practical and cost is relatively low. Another example is, such as a framework, gives a comprehensive solution from the interface layer to the database, and similar to Windows, strict three-layer technology is not suitable for this situation.
How to use hierarchical technology?
In a sense, the layer is actually a coarse particle size component. As we use component technology, it is also a great role of the layer. Its purpose is to make it easier to understand, and different parts can be easier to replace.
The basis of using hierarchical technology is the actual needs of software developers. If you are using some excellent object-oriented software development platform, then they generally recommend (or forced) you use a hierarchy mechanism. This is a major reference you use of layered technology. For most software teams with some experience, some software development experience will generally accumulate. It contains a lot of classes or components that are used in certain areas. These elements constitute a general hierarchy of a system. This level is also required when it is hierarchical. For example, some universal Currency objects used in applications or Organization objects. Analysis Mode A book is fully detailed in this type of object. This level is generally referred to as cross-domain layer, or is a tool layer (Utility Layer).
Many of the current software uses database mapping technology. The database mapping layer is very important for the enterprise application system, so it also needs to be included in the consideration. Database mapping technology is simple, but it is not easy to implement. If it is not necessary, use the ready-made frame, or use some of its design ideas. Attempting to build a large-scale mapping level is very high, you will have a lot of trouble. Database mapping technology knowledge, we also have a special space below to discuss.
How to store data (status)?
In the process of learning EJB, it must be a state and stateful concept. It can be said that the entire concept is the core of multi-layer system. Why do you say this? The state here refers to the state of the class, such as the attributes, variables, and the like. Due to the difference in state, the class also shows a difference. For multi-layer structures, the cost of creating and destroying a class is very large, and if the software supports distributed, it is especially true. So if there is a frequent call between different levels of the system - create a class, then destroy a class. This approach is very consuming resources. In the design of the application system, it is generally not alone using COM, which is this reason. So we naturally think of a classic design-buffer pool. Put the object in the buffer pool and remove one from the pool when needed, and place the object in the pool when you don't need it. This design idea can greatly improve efficiency. However, this is a harsh requirement for objects that can put in the pool - all objects must be different, that is, there is stateless. Only the buffer pool can be achieved.
In general, the technique of the object buffer pool is used on the intermediate business layer. Since there is no state in the intermediate business layer, there is a problem with a state shift. There are two choices here, one is forward movement, moving the state to the user end, most typical use cookie. This selection is generally related to the status and the user end, and does not need to be saved for a long time. Another option is post-shifted, move the state to the data layer, by the database to implement a persistent state, and submit the state to the business layer when needed. This approach is the most used in the enterprise application, but also increases the burden on the database.
Handling good interface
Due to the use of layered technology, it is necessary to re-evaluate the complex relationship between the class in the CS structure. The coupling between the typical layers should not be too large. Therefore, it is necessary to make a careful design layer between the design layers. Some distributed software systems (such as J2EE) are called in the form of the layer in the form of an interface. At the same time, only the interface of the target layer is only known between the different layers, and the specific implementation of the target layer is not known. This is like this. In the COM system, it is also necessary to publish the interface to the client while designing.
In the interface between the design layers, in addition to considering the constraints of the development platform, it is also a point that developers must consider. That is the business needs. There is often a lot of objects and methods in the business layer, and the relationship between them is also very responsible, but for other levels, it doesn't care about these details. Therefore, the interface published by the business layer must be simple and unrelated to the implementation. Therefore, you can use the FACADE mode of the design mode to simplify the interface between the intercom. This approach is very effective, and the SessionBean and EntityBean in EJB are distinguished from this design idea. Similarly, there is a problem with data transfer between different layers. If the physical node of different layers is still good together, if not, it is necessary to use distributed technology. Because the memory address coding of different machines is different, then there is a problem if an object reference is used between the interfaces. Therefore, the object will be packaged in a string, and then restore it to the target machine. All distributed platforms provide support for this technology, and there is not much to say. But this implementation technology will affect our design ideas, and a small amount of data directly uses a string to pass, if the data is large, it is necessary to use the object that encapsulates the data. The design of this type of object needs very carefully. In the design process, you can refer to some standard practices provided by the development platform. Similarly, the frequency of requests is also one of the difficulties. Over frequent operations from the backend data will increase the overhead of the system. Therefore, it is also necessary to consider the practical application when designing the calling method.
Efficiency
In general, software-oriented object-oriented designers design will be relatively perfect. But you need to pay a certain price. When programming on some large software platforms, some mechanisms of the platform are often needed. The most typical is the platform's transaction mechanism (most typical JTS including J2EE platforms, and MTS of the COM platform), but the implementation of the transaction mechanism often requires a large number of objects of the platform. In this case, the overhead of creating an object that supports transactions is very large. Having this problem has a way to provide transaction support only for objects that need to be supported. This means that a separate business entity class may need to be divided into two classes based on whether to support the transaction: the SELECT method for the business entity does not require transaction support, only the Update and Delete methods need to be supported. This is the point of view that does not match pure object-oriented designers. But this approach can get a relatively excellent efficiency.
The above figure divides a single business entity into different implementations.
It should be acknowledged that this improvement of efficiency has increased complexity. Because for the client, they don't care about specific implementation techniques. Require the client to call this class in one case, call another class in other cases, which does not comply with object-oriented design ideas, and also increases interlayer coupling and complexity. Therefore, we can consider using an interface or an appearance (see the FACADE mode in the design mode), and package the specific implementation, but only the part of the user is provided to the user. This skill will be mentioned in the following sections.
Taking iteration
Iterative practice in software design can also be applied to layers. According to your own experience, it is difficult to define all levels at the beginning. Unless there is a very rich experience, it is realized and the total design of the total or large or small gap. Therefore, the adjustment is imperative. Every iteration can improve the layered technology and have accumulated experience in the latter project.
The layered iteration here cannot be too frequent. Every iteration is a major revision of the architecture, which requires the progress of the software development, and will affect the progress of software development. However, the effect of successful iteration is very obvious, and it is possible to set up a stable architecture in the next development cycle, reduce the amount of code, and improve the efficacy of software quality. Note that do not let the trend can become a promotion of layered iterations. This is a problem that developers are often punished. This is not a shortcoming, which can only be called an occupational disease. The driving force of the layered iteration should be derived from the evolution of demand and the instability of the existing architecture has hindered further development. So this requires the technical supervisor in the team to have a very good grasp of technology. Reconstruction can help it itend. Sniff the bad smell hidden in your code and improve it. It should be said that iteration is a more intense practice, better practice is to adjust the architecture and level in the development. But this has a high requirements for teams, techniques, methods, and processes. Therefore iteration is still a major improvement means.
Segmentation in the layer
The hierarchical idea can also be applied to the interior of the layer. The segmentation in the layer is not fixed, and its drive factors are often considered for encapsulation and reuse. For example, in the business layer in the EJB system, entity beans are responsible for implementing business objects, so an application often has a large number of entity beans. The user does not need to understand each entity bean, for them, as long as it is fully capable of logic, but completing these business logic needs to deal with multiple entity beans. Therefore, EJB provides a session bean to encapsulate the entity bean, and the user only knows the session bean, and does not know the existence of the entity bean. This ensures that the reuse of the entity bean is well realized.
Interface programming
In the previous chapter, we mentioned an example of an interface design. Why do we advocate interface design? Martin Fowler pointed out in his analysis mode book, analyzing the problem should stand at the level of the concept, rather than standing at the level implemented. What is the concept of concept? Simply put is to analyze what the object should do, not how to analyze the object. The former belongs to the stage of analysis, the latter is a stage of design or even implementation. In the demand engineering, there is a game called CRC card, which is used to analyze the duties and relationships. In fact, the method is to perform object-oriented design from the concept level. Therefore, if you want to analyze from the conceptual level, this requires you to look at how the program represents the concept of the real world from the perspective of the domain expert. The following sentences are somewhat, from the perspective of implementation, the concept level corresponds to the contract, and the implementation form of the contract includes interfaces and base classes. Simply put, analyzing at the concept level is to design an interface (or base class) without care for a specific interface implementation (implementation is postponed to subclass reality). In conjunction with the above discussion, we can also infer that the interface should be in accordance with the concept of real world.
In another copy of Martin Fowler mentioned such an example, it is very good to explain the idea of interface programming:
Interface Person {
Public String Name ();
Public void name (String newname);
Public Money Salary ();
Public Void Salry (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; Public Int NumberOfsales ();
}
Interface Manager Extends Person {
Public void budget (Money Value);
Public Money BUDGET ();
}
It can be seen that in order to express the real world (here, the concept of employee is the concept of employee), the concept of engineers, salespersons, managers, and the code is designed inherited hierarchies according to people's natural opinions, and achieves reuse. Moreover, we can identify that the interface is relatively stable. Let's take a look at the implementation section:
Public Class Personimpflag Implements Person, SaleSman, Engineer, Manager {
//Mplementing Salesman
Public static salesman newsalesman (String name) {
Personimpflag result;
Result = new personimpflag (name);
Result.makesalesman ();
Return Result;
}
Public void MakesaSman () {
_jobtitle = 1;
}
Public Boolean Issalesman () {
Return_jobtitle == 1;
}
Public void Numberofsales (int value) {
RequireissaSman ();
_NUMBEROFSALES = VALUE
}
Public int numberofsales () {
RequireissaSman ();
Return_numberofsales;
}
Private void resireissalesman () {
IF (! ") Throw New PreconditionViology;" NOT A SALESMAN ");
}
Private int _Numberofsales;
Private int _jobtitle;
}
This is a method of implementation of an internal flag (INTERNAL FLAG). Here we just raise an example, in fact, we have a lot of solutions, but we don't care. Because as long as the interface is stable enough, the internal implementation has been allowed to change. If you are interested in implementation, you can refer to the articles of MATRIN FOWLER's role modeling or I am reading this article.
Through the above example, we can understand that the biggest advantage of interface and implementation is to modify the implementation code in the case where the client is unknown. This feature is very suitable for hierarchical technology. One is called between layers and layers. The layer and the layer is too high or too frequent. Design excellent interface can solve this problem. The other is to use in those unstable portions. If some needs have changed, the definition interface is also a solution. For an inappropriate example, design a good interface is like the usual sockets we use, or you can use regardless of how the plug changes.
Finally, it emphasizes that a good interface definition must be from demand. It is definitely not a programmer to think out.
Data mapping layer
In the design of each layer, it may be more confusing that the data mapping layer is. Due to the relationship of the space, we cannot discuss too much on this issue, which can only be thrown. If there is a chance, we can also talk about this topic.
Object-oriented technology has become a trend in software development, and more and more people have begun to understand, learn and use object-oriented technology. And most object-oriented technologies are only solved the object-oriented problem in memory. But fresh object-oriented problems mentioned in persistence. The mechanism-oriented mechanism and relationship model of object-oriented design has a great difference, which causes mismatch between object-oriented design and relational database design. The basic theory of object-oriented design includes coupling, aggregation, packaging, inheritance, polymorphism, and theory of relational data models is completely different. Its basic principle is the three paradigm of the database. The most obvious example is that the ORDER object includes a set of OrderItem objects, so 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, also That is to say, the pointer in the Order class points to ORDERITEM. Suppose the ORDER class and the ORDERITEM respectively correspond to two tables (the simplest mapping), then we want to implement the relationship between the two, which is through the ORDERITEM table (the same name), the foreign key pointing to the Order table. . This is two completely different settings. The role of the data mapping layer is to hide the existence of the relational database to the client.
It is very attractive to develop an object / relationship mapping tool. But it should be considered that developing such a tool is not an easy task, and it takes a lot of cost. In particular, the problem of manual processing data consistency and transaction processing. It is much more difficult than you think. Therefore, the best way to get an object / relationship mapping tool is to buy, not develop.
to sum up
A hierarchical concept is very important for modern software development. It is also the knowledge we must learn. There is no special place in the overall idea of the layered, but it is necessary to combine with your own development environment, you still need to pay a lot of efforts.
After completing the hierarchy, the software architecture is actually clarified. The following discussion will surround how to improve the architecture, how to make the problem of architecture stabilization.
