First, write first

Application layering may seem simple, but every programmer has a way of doing it, even beginners. How do you get hundreds of applications in a company to have a uniform hierarchy that most programmers agree on? This is not a simple matter. Next, we will discuss with you with real cases. First, we will ask you two technical questions:

Where would you like to put the service invocation code?

  • A presentation layer
  • B Business logic layer
  • C data layer
  • D public layer

How to organize VO(View Object), BO(Business Object), DO(Data Object), and DTO(Data Transfer Object)?

Different people will have different answers, so unify the application layer of the company to reduce development and maintenance learning costs. The unified application stratification should be large or small, simple and easy to use, and support a variety of scenarios. We adopt the IPO method: I is Input, O is Output, P is Process, one in, one out, one processing. The essence of the application system is a machine, is a processing equipment, in a processing.

The principle diagram of the IPO

Second, unified logical architecture

Unified application hierarchical logical architecture diagram

Job Description:

  • Folder layering method: The advantages of application layering are that the folder mode can be large or small, simple and easy to use, unified standard, can include 5 items, can also include 50 items, to meet the various scenarios of all business applications;
  • Call specification: In the development process, it is necessary to follow the constraints of the hierarchical architecture and prohibit cross-layer calls;
  • The bottom serves the top: user-centric, goal-oriented. Provide what the upper layer (business logic layer) needs and what the lower layer (data access layer) provides, not what the lower layer (data access layer) has;
  • Entity layer specification: DO is a data table object, not a data access layer object, not only for the data access layer; DTO is a network transport object, not a presentation layer object, not only for the presentation layer use; BO is an in-memory computing logic object, not a business logic layer object, and not only for the business logic layer. If access is restricted to this layer, it results in a large number of worthless object transformations within a single application. User-centric design of entity classes can reduce worthless duplicate objects and useless transformations.
  • U-type access: The downstream presentation layer is Input, the business logic layer is Process, and the data access layer is Output. The data access layer is Input, the business logic layer is Process, and the presentation layer is Output.

Iii. Our specific specifications

This specification has been in use for four years, involving hundreds of applications and over 200 developers, and is a successful practice. Next, I will use the downloaded TripOrderService and TripSellerMVCSite to illustrate the specific specifications. Here are the screenshots:

3.1 Naming rules of the project

Naming rules of the project: {full name of the product line}.{full name of the subsystem + Application name}.{Full name of the project responsibility}, for example: trip.seller.dto.

3.2 Project specification of business logic layer

Specification description:

  • 1. Naming rules of project names: {full English name of product line}.{full English name of subsystem + application name}.
  • 2. The class name ends with Logic, as in orderLogic.cs above.

3.3 data operation project specifications

Specification description:

  • 1, Each data operation project name is classified according to the database used, and then ends with DB. The specific naming rule is: {full name of the product line}.{full name of the subsystem + application name}.
  • 2. If multiple databases are involved, the class files under the data operation project need to be separated by the database name (ending in DB) to create folders, such as the TripOrderDB folder shown above.
  • 3. You are advised to use SQL statements instead of stored procedures in applications. No stored procedures are added to the database, but old stored procedures can continue to be used and modified.
  • 4. Paging It is recommended to use the latest features of databases (such as SQLServer) for paging and write each paging SQL directly to the application.

3.4 Entity class project specification

Data transfer object DTO specification

Specification description:

  • 1. Naming rule of DTO project: {full Name of product line}.{full name of subsystem + application name}.
  • 2. Storage specification of request parameter DTO entity class, response DTO entity class and its naming rule:
    • A, Request parameters DTO entity class is placed in the Request folder, and the naming rule is: end with Request, as in the figure above searchorderRequest.cs.
    • B. The Response DTO entity class is placed in the Response folder and named as follows: End with Response, as shown in searchorderResponse.cs.
    • C. If there are objects or enumerations in the attributes of the request parameter DTO entity class or the response DTO entity class, the classes and enumerations to which these objects belong are placed under the Common folder of the DTO project.
  • 3, If the request parameter DTO entity class and response DTO entity class have a base class to inherit, then we recommend to name the base class requestBase. cs, responseBase.cs. And these base classes are placed directly under the Common folder of the DTO project.

View object VO specification

Specification description:

  • 1, VO project naming rules: {full name of product line}.{full name of subsystem + application name}.ViewModel, as shown in the above trip.seller.viewModel.
  • 2. For each VO entity class, we use Controller name as the folder name to separate it, such as the Order folder in the figure above.
  • 3, VO entity class name naming suggestions:
    • The VO entity class ends with Input/Form/Query, as shown in searchorderInput.cs.
    • B. The response VO entity class ends in Output/List/Result, as shown in searchorderoutput.cs.

Business object BO specification (optional)

The BO entity class name ends with Model:

Specification description:

  • 1. Naming rules of BO project: {full name of product line}.{full name of subsystem + application name}.
  • 2. End with Model, as in orderModel.cs above.
  • 3. In order to simplify the design, BO project is optional, and folders can be built in DO project.

Data object DO specification (optional)

Specification description:

  • 1. Naming rule of DO project: {full English name of product line}.{full English name of subsystem + Application name}.Entity, such as trip.Seller.
  • 2, If multiple database access is involved, then you need to create folders according to the database name (ending in DB), such as the TripOrderDB folder above;
  • 3, table name +Entity end, as in orderEntity.cs;
  • 4, DO is a table object for CURD operation. For multi-table query request objects and return objects, new objects can be defined or existing objects (DTOS /BO) can be used to accomplish this.

3.5. Configuration specifications for database connection

Specification description:

  • 1. The database connection must be configured with read/write separation.
  • 2. Database connection strings are recommended to be encrypted.
  • 3, database connection configuration name naming rules: {database name ending in DB}_ read/write type, such as TripOrderDB_SELECT, TripOrderDB_INSERT.

3.6 specification of configuration files

Specification description:

  • 1. All configuration files (except web. config files) must be placed in the config folder.
  • 2. All configuration files (except web. config files) are separated according to different environments. The specific naming rules are as follows: {Function module Name}.{Environment name for short}.config, where the local environment name is Dev, the Test environment name is Test, and the formal environment name is Prod, as shown in the figure above appSetting.dev.config.
  • 3. Keep the web. config configuration file clean, leaving only the environment Settings node.

3.7. Specification of static resource files

Specification description:

  • 1, public static resource files (CSS, JS, image, etc.) in another static site, unified by the front-end development and maintenance. Generally, CSS files are stored in the CSS folder, JS files are stored in the JS folder, and image files are stored in the IMG folder.
  • 2. Js files related to a business can be placed under the PresentationLayer of their respective business projects for easy debugging by developers, and js files can be placed under the js folder of the project.
  • 3, static resource files must be managed by version number, in case the site still uses the old version of static resource files due to the client browser cache after update:

<script src=”~/js/order.js? [email protected]”></script>

Write at the end

4.1. Question answers

Q: Where does the service invocation code go? A presentation layer, B business logic layer, C data layer, D common layer.

Our specification is to unify the data resource access layer, which is CALLED C. The upper layer provides the service, the lower layer invokes the service, and the middle handles the business logic.

Q: How to organize VO(View Object), BO(Business Object), DO(Data Object) and DTO(Data Transfer Object)?

There are usually two approaches, limited access and unlimited access, which can be selected, compromised, or tailored according to the needs of the actual project. We use the latter, placing EntityLayer as a generic object on the left, as described in the EntityLayer specification:

“DO is a data table object, not a data access layer object, not only for the data access layer; DTO is a network transport object, not a presentation layer object, not only for the presentation layer use; BO is an in-memory computing logic object, not a business logic layer object, and not only for the business logic layer. If access is restricted to this layer, it results in a large number of worthless object transformations within a single application. Designing entity classes with the user in mind reduces the number of worthless duplicate objects and useless transformations.”

Q: What should I pay attention to when writing application layered sample code?

Code that applies the layered paradigm is very difficult to write well, very controversial, and very difficult to please everyone. In practice, we follow the following points:

The main value of applying the layering paradigm is to clarify the responsibilities and interactions of the layers, what the responsibilities of each layer are, what to do and what not to do, and the dependencies and interactions between layers;

Customization: Reduce the need to write generic help classes. If there are a large number of the same help classes in every application, this is an architectural problem. In our hundreds of online applications, there is less common code, including paging help, database help, caching help, MQ help, logging help, AOP help, threading help. The focus of business applications is to serve the business. Every application is special and requires personal customization. There is very little common code, and if there is one, it should be addressed by a framework or component.

Less is more: lots of scenarios, lots of references, lots of different people, lots of time involved, so try to do what everyone agrees is the right thing to do, bottom up, and reduce the number of controversial code examples, otherwise a mistake will be magnified a hundred times and a controversial specification will be hard to implement.

Pursue simplicity: Code can be written at three levels: simple, complex, and simple. The first simple is not simple, the second complex is to know the complex, the third simple is to know the simple choice. The sample code should be simple enough to be easily extended to support complex scenarios, yet simple enough for a novice programmer to operate.

Cohesion is greater than decoupling: what is cohesion? Cohesion is a common goal within the department, and then people work closely together. What is decoupling? Decoupling is defining responsibilities between departments and then reducing unnecessary connections. An app, like a department, should have a common goal and responsibility and work closely together.

In other words, there should be fewer unnecessary contract interfaces within applications (as between companies), fewer unnecessary dependency injection implementations, and fewer unnecessary and costly decoupling. Everything is simple and practical, oriented by the output of application value and the goal of application (interface or interface).

4.2 Demo Download

LayerDemo download address: https://github.com/das2017/LayerDemo

The list of topics covered in this series (not published in that order) is as follows. If you are interested, please follow:

  • Introduction: Small and medium-sized R&D team architecture practice three points
  • Cache Redis: Quick start and application of Redis
  • Message queue RabbitMQ: How to use the good news queue RabbitMQ?
  • Centralized log ELK: A centralized log ELK of architectural practices for small and medium r&d teams
  • Task scheduling Job: Task scheduling Job in the architectural practice of small and medium-sized R&D teams
  • Metrics: What does app monitoring do?
  • Microservices Framework MSA: This is what you want. NET stack microservice architecture practice
  • Solr: Solr for Small and medium-sized R&D Team Architecture Practices
  • Distributed coordinator ZooKeeper: Architectural practices for Small and medium-sized R&D teams
  • Widgets: a collection of widgets for small and medium-sized r&d team architectural practices
  • Release tool Jenkins
  • Overall architecture design: How to do e-commerce enterprise overall architecture?
  • Single project architecture design
  • Unified application stratification
  • Debugging tool WinDbg
  • Single sign-on (sso)
  • Enterprise Payment Gateway
  • “Article

The authors introduce

Zhang Huiqing, an IT veteran of more than 10 years, has successively served as architect of Ctrip, chief architect of Gooda Group, CTO of Zhongqing E-Travel and led the upgrading and transformation of the technical architecture of the two companies. Focus on architecture and engineering efficiency, technology and business matching and integration, technology value and innovation.

Thanks to Yuta Tian guang for correcting this article.