Veil Framework Design Concept

Project address: http://github.com/honovation/veil

Design philosophy as a framework: Changing without change is the only criterion for testing all Architectures

We believe that the framework is not only designed to save developers time, but also to allow you to write a blog system in five minutes. More importantlyProgramThe logic provides an organizational structure. As we know, software development is the art of management complexity. Managing the complexity of software business logic requiresCodeHave a good organizational structure. Over the years, Jin yuliangyan has summarized the modular design method of "high cohesion and low coupling. The veil framework is just an effort and attempt to implement modular design.

Modular Design is not a new concept. Even the module of C can be called itself modular. Veil features a thorough modularization. For example, we sometimes place things in different places.

• If the installer is centrally managed, some implementations of each module must be leaked to the installer.
• If scripts are centrally managed during running, you need to know how each module runs the scripts in a centralized manner.
• If the code is hierarchically managed, the functions implemented by each module must span multiple layers and be separated into several separate directories.
• If the page and Code are not separated, the module should be divided into two parts: code and page.
• If JavaScript and CSS are stored separately, module changes will not stop jumping between related JavaScript and pages.

Sometimes we don't separate things.

• Using the same table method and implementation, even for different functions, we will put the code in the same "model", no matter how big it is.
• Code at the same layer can be referenced with each other without authorization, even if some CMS has transaction code in some cases, which is irrelevant
• Code for calling external services such as Web Service is scattered in every corner of the code and can be referenced at will.

Therefore, veil reflects on the traditional "order" in a sense. We put a lot of things that should be put together out of all kinds of difficulties and have taken it for granted. Some things that should not be put together are piled up together in the form of "hierarchy" and "oo", making the code complex and difficult to manage. Veil ignores the order we are used to and simply judges what should be put together from the perspective of "high cohesion and low coupling", and what should not be put together.

The final goal is not for oo, not for achieving any architectural ideal. Even achieving "High Cohesion and low coupling" cannot be called a goal. In the end, a framework and the architectural design ideas behind it can only be tested to respond to changes. That is to say, architecture a and architecture B can also be used to build functions. In addition to static tests (whether functional and non-functional requirements are met), the more important dynamic tests are the "dynamic" capabilities. When we need to add or delete functions and move the module's responsibilities to each other, whether the code can be changed or not is not afraid of making changes or chaos is what truly reflects the power of the Code. No design can anticipate all the needs at the beginning. A good architecture is to make changes to the design. In our opinion, to achieve this goal is a very simple principle, that is, to divide and conquer, and to ensure the "High Cohesion and low coupling" relationship between the components to be divided. In the design process of veil, the pursuit of modularization is to the extreme. Whether or not it can help you, whether it can really meet the above-mentioned help you improve your ability to respond to demand changes, remains to be tested in practical use.

As a database: it will be paid back sooner or later

The relationship between the framework and the application is that the framework provides the skeleton (so-called architecture) and the application provides the meat (so-called business logic ). However, no matter what the framework is, some libraries will be provided for use in the end. The author will always expect to help the application with the "public" repetitive work. This simplicity is often the so-called highlight of a framework. But we know that the material is conservation, and the complexity of the Code is also conservation. To implement the same function, you do not need to write more code in the application, or use more libraries to implement some functions. In the long run, it will take a long time to restore the problem. All the functions implemented by the application are still part of the application. From the perspective of dependency, the runtime of your language (such as the standard Python Library ), the following C runtime environment, operating system APIs, hardware drivers, and even CPU commands are part of your application. Once a feature fails, it may be a CPU error, or your code is wrong, or it may be from your code to every step of the CPU.

Since we realize that the database is also a part of the application, we need to think about when to use the database and what kind of database we need. What kind of library APIs does veil need to provide to applications. We believe that there are three trade-offs between the design and use of the affected database:

• Complexity of the problem domain. If the problem itself is too complex to allow database users to use the APIS provided by the database with peace of mind, this situation may not be suitable for encapsulation into a database. For example, SQL is a complicated problem domain. After ORM encapsulation, it actually re-invented a query language. The result is that as an ORM user, not only the new query language provided after the ORM encapsulation, but also the SQL (related to execution efficiency ), we also need to know the translation relationship between the query language and SQL after the orm encapsulation (otherwise, how can I let the ORM translate the desired SQL when there is a performance problem ).
• Whether the Library's own API is well designed and whether internal implementation is leaked. If the problem is not complex, such as calculating the MD5 value of a string. Therefore, you only need to design the API well. Generally, you do not need to worry about internal implementation.
• Library code quality. However, sometimes we are forced to understand the internal implementation of some libraries. For example, if hibernate of version 1. NET is used to handle the lazy load list in the case of concurrency, different connections may be obtained from the connection pool. After thoroughly checking your code, we found that the library code had bugs.

For the above three items, no matter which one has a problem, it will bring us into a state of debt repayment. It takes ten times to understand the code that we don't know very well and is often too complicated. Because the database faces thousands of users and solves various problems. For example, Linux Process Scheduling can be implemented in a comprehensive manner to meet the requirements of different computing scenarios. If one day we are forced to know how our processes are scheduled by Linux, the time needed can be imagined. Even if the library solves a clear and small problem, well-designed APIs, and its own code does not have any problems, we may still encounter, the problem may be slightly changed, and the database is incomplete to solve our problem, but it cannot be solved completely. In this case, many people may choose to use and modify the library, either fork or submit it back.

In short, it is the sentence that will be paid back sooner or later. The veil principle is straightforward, that is, simple and crude. If you want to encapsulate it, try to solve clear and small problems as much as possible. The API does not leak implementation, while ensuring quality. Do not insert too much magic between the application code and the final implementation.