最近、プロジェクトで自分でビューを作成する必要があり、それから学び、ちなみにJavaでのdtoの魔法も復習しました。
目次
ビューの概念とビューの作成の概要
まず、ビューの概念を理解しましょう。ビューは仮想テーブルであり、データ自体を含まない論理テーブルです。select ステートメントとしてデータ ディクショナリに格納されます。
There are generated rules in the view, which are similar to our query statement . 実際、ビューは、一連の結合テーブル クエリによって生成された論理テーブルです。
ビューはベース テーブル(ビューの作成に使用されるテーブル) のデータの一部を表示できます。単一のテーブルによって生成されたビューは変更およびクエリできますが、複数テーブル クエリによって生成されたビューは変更できません。次のポップアップ ウィンドウが表示されます (ビューのデータを変更する必要がある場合は、ビューが作成されたベース テーブルで直接変更することをお勧めします)。
ビューを使用する利点:
-
現在の業務に不要なベース テーブルのフィールドをシールドして、クエリをより効率的にすることができます.たとえば、ベース テーブルには 100 フィールドがありますが、必要なフィールドは 10 だけです.10 のビューを作成して使用するだけです.田畑。
-
テーブルのデータ セキュリティを保証できます. ビューを使用するユーザーは、クエリを許可された結果セットにのみアクセスできます. たとえば、このテーブルを使用するユーザーにテーブル内の 10 フィールドをクエリできるようにしたい場合、そのため、10 個のフィールドを作成します。クエリを実行しているユーザーがテーブル内の他のフィールドを見ることができないように、ビューは問題ありません。
-
ビューを使用するユーザーに対するベース テーブルの構造の変更の影響を保護でき、テーブルの新しいフィールドはこのビューの表示効果に影響しません。
ビューを作成する: ビューを作成するさまざまな複雑な状況についてはここでは説明しません. 実際、ビューを作成するロジックは、単一テーブル クエリまたは複数テーブル ジョイント クエリを介して生成されるため、クエリ SQL ステートメントに似ています。ただし、さらにいくつかのルールがあります。以下のビューの作成を参照してください。
使用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语句中引用了不可更新视图； 上記のビューのプラグイン ステートメント:
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`))
);ビュー vs. DTO? VO
以下は、プロジェクトを作成するときのdto に関する私自身の理解です。
Java には dto (データ転送オブジェクト)と呼ばれるクラスがあり、データ転送オブジェクトとも呼ばれます。これは主に、表示する必要があるデータを返すか、フロントエンドによって送信されたパラメーターを受け入れるために使用されます。データを表示するという面では、ビューと併用するのが直接クールです（もちろん、プロジェクトがこの種のデータの階層化についてより厳密である場合は、ビューに対応するエンティティ クラスに VO を使用することをお勧めします）。 , ただし、ほとんどの場合、アプリケーション シナリオでは、DTO と VO の属性値は基本的に同じですが、設計レベルでは、両者の間には依然として本質的な違いがあります. DTO は、サービス層が必要とするデータを表します. receive (バックエンド インターフェイスがパラメーターを受け取るため) と返されたデータ (返されたデータは必ずしもビューに対応するとは限りません。複数テーブルの共同クエリの結果にカプセル化される場合があります)、および VO はそのデータを表します。プレゼンテーション層に表示する必要がある. 要件が明確でクライアントが1つしかない場合は, VOとDTOを組み合わせる必要はない. DTOデータ. 一般にVOは主にビューのオブジェクトに反映され, WEBページのページ全体のプロパティをオブジェクトにカプセル化し, VOオブジェクトを使用してコントロール層とビュー層の間の送受信を行う. .)
例: フロント エンドが 12 個のパラメーターを渡しましたが、それらを受け取るにはインターフェイスを使用する必要があります. インターフェイスのパラメーターに 12 個のパラメーターを記述して受け取ることはできません. 直接 dto を作成する方が適切な場合があります.入力データの属性名は同じです。そうしないと、mvc が解析およびマップするときに問題が発生する可能性があります。
別の例: フロント エンドに表示する必要があるデータは、5 つのテーブルからクエリする必要があり、クエリの結果は数十のフィールドになり、それらすべてを 1 つずつマップにカプセル化することは不可能です。 dto を使用する方がよい場合があります。
上記の文章を理解するには、擬似コードを使用します。
フロント エンドに表示する必要があるデータ: 名前、年齢、お金、家。名前と年齢はユーザー テーブルにあり、お金と家は資産 (資産) テーブルにあります。
エンティティ クラスとデータベース テーブルの間のマッピング関係では、ユーザー エンティティ クラスの名前と年齢の属性の型は、ユーザー テーブルの名前と年齢、および資産のお金と家の属性の型に対応する必要があります。エンティティクラスは、資産テーブルのエンティティ クラスと同じでなければなりません。お金と家の間には 1 対 1 の対応があります。
マネーは資産テーブルに int データ型で格納されます(これは単なる比喩であり、実際の運用ではこのように格納されることは絶対にありません) が、フロント エンドで表示する必要があるコンテンツは、そのマネーが 1 より大きいことです。百万人は次のように表示されます: 1,000 万人を超える金持ちはリーガルとして表示されますが、このフロントエンドは直接判断して表示できますが、現在はバックエンドで変換を実行する必要があります (変換サービスはかなり多くあります)。このタイプのデータは、フロントエンドとの通信結果によっては、このフロントエンドでも扱えます) ので、データ表示に dto を使用する場合、dto 内の金額は string 型を使用する必要があります。(だからここで比較します: Java の資産エンティティ クラスの money は int (データベースの資産テーブルに対応) を使用し、dto の money 属性は文字列型を使用します)
換算は判定で設定すればよく、例えばお金＞1000000ならdtoのお金をリッチに設定します。