Views vs. DTOs? VO

Recently, I need to create a view by myself in the project, and then I will learn it, and I also reviewed the magic of dto in java by the way.

Table of contents

Introduction to view concepts and view creation

Views vs. DTOs? VO 


Introduction to view concepts and view creation

Let's first understand the concept of a view: a view is a virtual table, a logical table that does not contain data itself. Stored in the data dictionary as a select statement.

There are generated rules in the view, which are similar to our query statements . In fact, the view is a logical table generated by a series of joint table queries.

The view can display part of the data of the base table (the table used to create the view); the view generated by a single table can be modified and queried, and the view generated by the multi-table query cannot be modified, and the following pop-up window will appear: (It is recommended that if you need to modify the data in the view, you can directly modify it in the base table where the view is created)

 Benefits of using views:

  • You can shield the fields in the base table that are useless to the current business to make the query more efficient. For example, there are 100 fields in the base table, but we only need 10 fields, just create and use the view with 10 fields.

  • It can guarantee the data security in the table. Users who use the view can only access the result sets that they are allowed to query. For example, we only want users who use this table to be able to query 10 fields in the table, so we create the 10 fields. The view is fine, so that other fields in the table can not be seen by the querying user.

  • It can shield the impact of changes in the structure of the base table on users who use the view, and new fields in the table will not affect the display effect of this view.

Create a view: The various complex situations of creating a view will not be described here. In fact, the logic of creating a view is generated through single-table query or multi-table joint query , so it is similar to the query SQL statement, except that there are some more rules. . See the creation of the view below:

使用CREATE VIEW语句创建视图
语法格式:
CREATE [OR REPLACE] VIEW 视图名 [(列名列表)]
AS select语句
    
       
要通过视图更新基本表数据,必须保证视图是可更新视图。对于可更新的视图,在视图中的行和基表中的行之间必须具有一对一的关系。如果视图包含下述结构中的任何一种,那么它就是不可更新的:(使用视图的主要原因就是为了查询,所以对于可更新的视图这里就不在赘述了)
(1)聚合函数;
(2)DISTINCT关键字;
(3)GROUP BY子句;
(4)ORDER BY子句;
(5)HAVING子句;
(6)UNION运算符;
(7)位于选择列表中的子查询;
(8)FROM子句中包含多个表;
(9)SELECT语句中引用了不可更新视图;  

The plugin statement for the view shown above:

create or replace
algorithm = UNDEFINED view `v_t_dish_dish_flavor` as
select
    `d`.`name` as `name`,
    `d`.`price` as `price`,
    `df`.`name` as `flavorName`
from 
(
    `dish` `d`left join `dish_flavor` `df` on ((`d`.`id` = `df`.`dish_id`))
);

Views vs. DTOs? VO 

The following is my own understanding of dto when writing a project :

There is a class in java called dto ( Data Transfer Object ), also known as data transfer object, which is mainly used to return the data that needs to be displayed or to accept the parameters transmitted by the front end . In the aspect of displaying data, it is used together with the view, which is directly cool ( of course, if the project is more strict about this kind of data layering, it is better to use VO for the entity class corresponding to the view , although in most In terms of application scenarios, the attribute values ​​​​of DTO and VO are basically the same , but there are still essential differences between the two at the design level. DTO represents the data that the service layer needs to receive (for the back-end interface to receive parameters) and the returned data. (The returned data does not necessarily correspond to the view, it may be encapsulated in the result of multi-table joint query), and VO represents the data that needs to be displayed in the presentation layer. When the requirements are clear and there is only one client, it is not necessary to combine VO and DTO is separated, and VO can be considered when it is not clear and a display page may require multiple DTO data. In general, VO is mainly reflected in the object of the view, and encapsulates the properties of the entire page for a WEB page into an object. Then use a VO object for transmission and exchange between the control layer and the view layer .)

For example: the front end has passed 12 parameters, and you need to use the interface to receive them. You can’t write 12 parameters in the parameters of the interface to receive them. It may be more appropriate to create a dto directly. The attribute names of the incoming data are the same, otherwise there may be problems when mvc parses and maps.

Another example: the data that needs to be displayed on the front end needs to be queried from 5 tables, and the result of the query is dozens of fields. It is impossible for you to encapsulate all of them into the map one by one. Using dto may be a better way.

 Use pseudocode to understand the above passage:

The data that needs to be displayed on the front end: name, age, money, house, where name and age are in the user table , and money and house are in the asset (asset) table .

In the mapping relationship between the entity class and the database table, the type of the name and age attributes of the User entity class must correspond to the name and age in the user table, and the types of the money and house attributes in the Asset entity class must be the same as those in the asset table. There is a one-to-one correspondence between money and house.

Money is stored in the int data type in the asset table (this is just a metaphor, it is definitely not stored in this way in actual production), but the content that needs to be displayed on the front end is that money greater than 1 million is displayed as: rich people greater than 10 million are displayed as Regal, although this front-end can be directly judged and displayed, but now the demand is for your back-end to perform conversions (there are quite a lot of conversion services of this type of data, depending on the results of communication with the front-end, this front-end can also handle it) , so when using dto for data display , the money in dto should use string type. (So ​​here is a comparison: the money in the asset entity class in java uses int (corresponding to the asset table in the database), and the money attribute in dto uses string type)

It is enough to set the conversion by judgment, for example, if money > 1000000, set the money in dto to rich.

Guess you like

Origin blog.csdn.net/weixin_53142722/article/details/127443172