Framework layer:
SOA
In this article, I will introduce my understanding of these XXX concepts one by one. In fact, every concept is not inexplicably generated but has a background. These fashionable terms are not used to show off, instead, we really need to understand what they are doing, and the framework should never be used in disorder or in disorder. Instead of using all these resources to your system, it is a powerful system, it is best to be suitable and maintain a simple and reliable principle. The so-called SOA is literally a service-oriented architecture. Some people do not say that SOA is actually already SOA. Some people talk about SoA but are only using Web Services. SOA can be big or small. You can consider service calling as SOA, or think that service calling is only a small part of SOA. I personally think that the idea of SOA is to upgrade the business logic from class library encapsulation to service encapsulation, and provide services through different encoding formats of different channels, so that services can be reused between heterogeneous systems. To put it bluntly, code can be reused from the local machine to cross-machine. In the simplest way, encapsulate components into self-made services and exchange messages to use the functions provided by services. This is SOA, but this is only the beginning of SOA, for example, have you ever thought about how to solve the following problems?
Can your service be used by external heterogeneous systems? Well-developed 5-year UI front-end framework!
If your service needs to call another service, how can you handle complicated call relationships and monitor the entire call process?
How can service calls be incorporated into transaction control?
There are more and more services and interfaces. How do I know which service and which interface should I call?
What should I do if the API version is upgraded?
There are too many calls to the service. How does one implement load balancing and limit the number of calls?
How to ensure security and restrict anonymous service calls?
How to test the service?
What if a service call fails?
How can I upgrade and redeploy services?
Therefore, SOA not only calls services, but also has a lot to do in terms of monitoring and governance. SOA can be big or small. In any case, in terms of concept, SOA is indeed an improvement. complicated logic is encapsulated into services. A complicated system may call different services, every service is autonomous, which reduces the overall complexity of the system. In fact, if the complexity of a complex system is 10000, the layer-4 Implementation of 10*10*10*10 can greatly reduce the complexity, as long as each layer has 10 complexity, the upper layer calls the lower layer. If OSI is not a layer-7 model, it is hard to imagine how to deal with the entire complex process.
Well-developed 5-year UI front-end framework!
RPC
It is a remote process call. RPC (RPC in the broad sense here) can also be a method of SOA implementation. SOA is not necessarily implemented through Web Services. In terms of implementation principle, RPC is not very complicated. It is nothing more than a proxy on the client, collecting the remote methods and parameters to be called by the client, and then serializing them into messages and committing them to the remote, after the remote connection, the message is deserialized to dynamically execute the methods required by the client (including creating corresponding objects), and then return the result to the client through another message, of course, there are too many details. Generally, TCP or HTTP or UDP is used for the channels on which the client and server exchange data.
ORM
Object relationship ing solves the problem of inconsistent Impedance Between the object-oriented system and the database. We all know the definition of ORM. What I want to talk about here is that the starting point of ORM is good. In some applications, Orm can indeed improve code readability and increase coding efficiency. I personally think that ORM is useful, not all data access is suitable for using the ORM framework. Java SSH is also a little misleading. Struts is not the only method to implement MVC, and spring is not the only method to implement IOC, hibernate is not the only way to implement data access. I think ORM:
It is suitable for enterprise applications where the domain is complex, there are many tables, there are many relationships between tables, and the access volume is relatively small.
It is not suitable for Internet applications with relatively simple services, few relationships between tables, and large traffic volumes.
It is easy to get started with Orm, but it is not so easy to use it properly:
If the SQL statement is not correctly used, a large number of SQL statements may be generated, which is unknown to the user.
If not correctly used, it is likely to pull too much unnecessary data, which is unknown to the user.
If the SQL statement is not correctly used, it may produce SQL statements with low performance, but the user does not know.
Therefore, even Using ORM requires an eye on the SQL statements produced by Orm, and we need to know how to perform delayed loading, cascading loading, and primary key caching in Orm, only by understanding these mechanisms can we make good use of the Orm. If we are not familiar with the Orm, if we are working on an Internet system, I think it is still a bit peaceful, and SQL statements are accurate and efficient. Of course, some people may say that if SQL is used, the business logic may not be in the Code. In fact, it depends on how to write SQL statements, if SQL is used as a bridge between databases and programs, this is not a problem. If you make some judgments in SQL and make some calculations, it is your own business. Well-developed 5-year UI front-end framework!
IOC
Controlling reverse dependency injection is a very practical concept. Some people do not realize why they want to use IOC even after they use IOC. I always like to ask why they want to use containers to create objects during the interview. What is wrong if they manually create new objects? Some people say that the performance of manual new operations is not high, and the container creates a unique object, so I will ask myself that the same is true for writing a singleton object, why is container creation required? In fact, this understanding is incorrect. I personally think that the life cycle of the management object is only one function of the IOC container. The significance of the IOC container is:
Manages the relationships between objects. In OO, combination is very useful. If there is a complex relationship between objects, we must construct this relationship when we are new objects. These relations are actually written to the code. In addition, the Code directly writes the actual type to death, reducing the meaning of interface programming. If you can configure this relationship in the configuration file according to your own needs, and the container dynamically creates the relationship between the object and the object, we will extract the dependency from the code to the outside, injected externally. In a layered application, we can not only inject parallel-level objects, but also lower-level objects to implement automatic injection from top to bottom, making the entire system very flexible.
Manages the lifecycle of objects. Sometimes a singleton or a new object is generated, and there are also objects with special declaration cycles Based on threads and requests. If the manual code is used to manage the Declaration cycle, it is very troublesome, second, it is not easy to adjust. Using containers to manage object declaration cycles is simple and efficient, and we can easily extend the type of lifecycle by providing dictionaries with different declaration cycles for containers.
AOP
Aspect-Oriented Programming is important for separation of duties and improving testability. Generally, code can be woven in two ways: static and dynamic. The so-called static is to directly change the class to be packaged before compilation, and then encapsulate the focus entry method into the compilation enhancement. The so-called dynamic is the dynamic modification of the code during runtime, the dynamic compilation of runtime enhancements. Once we have AOP, our business-independent code, such as transactions, logs, permissions, and caches, will not appear or be mixed into the Business Code, you can configure as needed to enhance these cross-cutting concerns for any code. Once the code has been modified, we only need to modify the configuration, instead of searching for modifications in thousands or tens of thousands of places in the code. Well-developed 5-year UI front-end framework!
MVC
MVC is a good solution for websites, especially Internet websites. The advantages of MVC are as follows:
Separation of duties is no longer a combination of all codes. Separation of V and C is particularly important.
Separation of duties has long been possible for unit testing, and testability is also an important part. It is very important to perform unit testing for C.
Most MVC frameworks provide the collection points of AOP, which can automatically execute and replace cross-node concerns when implementing separation of duties.
To implement MVC, we should not only use the MVC framework, but also implement it as much as possible:
Cross-cutting concerns such as caching, permissions, and logs in C must be extracted and implemented through AOP. Do not mix with other business logic in C.
Actions in C can be reused as much as possible, and the results of actions can be reused as much as possible.
You can consider combining MVC and IOC to inject C into some services or Dao dynamically.
For V, try to ensure that V does not contain backend code. V allows the front-end development to directly edit the code, and the backend development can embed simple tags. If the VM is clear, the frontend can even write V directly.
TDD
Test-driven development is a big concept. Various platforms also have various frameworks to implement mock for unit testing. It is useless to use tools without correct coding concepts. to implement all the code, you can use unit tests to verify the following factors:
The program does not have a complex context environment, or the context environment can be simulated. Otherwise, how can we test it?
The role of the program module is single and clear. If a module does dozens of tasks and has hundreds of branches, it is difficult to test. The finer the granularity of the test, the easier it is to test.
The reason why TDD cannot be performed in most projects or even unit tests is that it is often time-consuming and only has time to implement the most basic business logic, in fact, unit testing does not take less time to code than the actual code, or even more. I personally think that, depending on the nature of the project, unit test TDD is of little significance if the project is originally crud or a temporary project. However, if this project is a class library or framework project to be used by many people, it cannot be imagined that there is no unit test:
If a Class Library provides 100 functions, you cannot Manually test these 100 functions after modifying a point. This must be done through automated means.
The class library needs to ensure that all boundary conditions are taken into account. Manual or black box tests are difficult to cover all situations.
If your class library does not provide unit tests, how can class library users verify the availability of the class library in their execution environment? Therefore, it is not just for your own use, but also for others to use your unit test to ensure that the class library works normally in their own runtime environment. Well-developed 5-year UI front-end framework!
Others
Here, I would like to sum up that I personally think that MVC and IOC are the most needed among so many XXX users. As for AOP, it is certainly better. As for orm and SOA, it depends on the needs, for TDD, if you are writing a class library or framework, it is necessary, otherwise it is hard to imagine how high the stability of this set of code will be. In addition to the above mentioned XXX, there are still many things that need to be implemented as the basic framework. I have drawn a brain image for reference: http://www.iteye.com/topic/1134828. As a framework, I think there are some elements that need to be met:
It is very easy to keep the external interface of the framework as much as possible. Complicated things should be processed inside the framework and transparent to users of the framework.
Framework exception handling needs to be improved and logging should be improved. The framework is transparent to developers, therefore, it is best to indicate in the exception information and log information how callers and framework users should do to solve this problem, rather than simply saying what is wrong.
A complete framework should have a built-in performance detection mechanism, or provide HTTP interfaces to let the outside know the running status of the framework.
The framework should be tested to ensure that the framework runs normally in different thread environments and different configurations.
It is best to have a performance test on the framework, so that users can identify the performance provided by the framework so that they can correctly determine whether they can meet their own needs.
My Architecture Experience series-backend architecture-framework layer
