JavaアーキテクチャにおけるVO、DTO、DO、BOの違いとつながり(超詳しい解説)



序文

このブロガーは、CSDN を使用して、彼がソフトウェア開発を勉強する過程で個人的に得た経験と知識を記録します. 興味のある友人は、ブロガーに注意を払うことができます! 人は一人で速く行けるかもしれませんが、大勢で行くと遠くまで行けるのです!

1. コンセプト

Java プログラミングでは、VO、DTO、DO、および BO という 4 つの用語はすべて、異なるオブジェクト タイプを表します。これらの違いと関係は次のとおりです。

1、VO(ビューオブジェクト)

VO (View Object)、フロント エンドと対話するビュー オブジェクトを表すために使用され、その機能は、指定されたページ (またはコンポーネント) のすべてのデータをカプセル化することです。実際には、ここにはVOフロントエンドが表示する必要があるデータのみが含まれています. データの作成と変更の時間など、フロントエンドが必要としないデータについては、送信されるデータのサイズを小さくし、データベース構造を漏えいから保護しますが、VO反映されるべきではありません。

2、DTO(データ転送オブジェクト)

DTO(Data Transfer Object)、データ転送オブジェクトを表すために使用され、通常はDTOプレゼンテーション層 ( Controller) とサービス層 ( )Serviceの間のデータ転送オブジェクトに使用されます。概念はDTOと似ており、一般的にフィールドは基本的に同じです。ただし、 と の間にはいくつかの違いがあります。この違いは主に設計コンセプトにあります。たとえば、使用するサービス異なる場合があります。VODTOVOAPIDTOVO

3、DO(データオブジェクト)

DO(Data Object)、永続オブジェクト。これは、Dao永続レイヤーのデータ構造と 1 対 1 のマッピング関係を形成します ( )。永続層がリレーショナル データベースの場合、データベース テーブルの各フィールドはPO属性 (通常はentityエンティティ クラス) に対応します。

4、BO(ビジネスオブジェクト)

BO(Business Object): 通常、ビジネス ロジック層で使用されるビジネス オブジェクトは、ビジネス ロジックの実現を表します。BOは主に、データ検証、データ処理、ビジネスロジック処理などを含むビジネスロジックの処理を担当します。BO は、複数の DO を呼び出し、複数の DO を組み合わせて、完全なビジネス プロセスを形成できます。

2. Vo はなぜ存在するのですか?

プロジェクトでは、他の人が直接 DTO を書き、闊歩コメントを書き、フロントエンドに直接戻るのを見ました。次に、DTO をフロントエンドに直接返す代わりに、なぜこれを行うことが推奨されないのかを考えてみてください。

開発プロセスの観点から、フロントエンドとバックエンドは、パラメータを返したり渡したりするためのプロトコルの定義として、最初にvoandparamを使用します. プロトコルを定義する前に、実際のビジネスロジック処理がないため、あるdto

プロジェクトの全体的な考察からdtoオブジェクトがフロントエンドに渡された場合、serviceレイヤーは を返しますdto.serviceレイヤーのすべてのメソッドが必ずしもpublicメソッドであるとは限らず、メソッドが存在します.メソッドも を返すprivate場合, 一部はそうではありません.一部はフロントエンド用であるため、ごちゃごちゃになり、分離がなくなります。privatedtodto

フィールドの変更に関してはserviceレイヤーメソッドを共有することができます.1serviceつのメソッドが返すものは、dto多くのメソッドでcontrolller使用される可能性があります.現在ではなくても、将来的には可能になるかもdtoしれません.メインを含むなど、多くのパラメータがあります.テーブル情報、サブテーブル情報ですが、一部の情報voしかdtoフロントエンドに渡されず、フロントエンドへのリクエストごとに見えるデータが異なるため、dto共有され、パーソナライズされていますvodto非常に大きい. インターフェイスの要件が変更、変更dto、またはフィールドを追加すると、インターフェイスは新しく追加されたフィールドをフロントエンドに直接返すため、(インターフェイス出力データの冗長性、安全でない)。同様に、dtoフロントエンドに表示されるインターフェースが、ある要件により特定のフィールドを削除するように指示されている場合、このフィールドはdto多くのインターフェースから参照されているため、一度削除すると問題が発生します。

したがって、全体的な構造に関しては、vo が存在する必要があり、dto をフロントエンドに直接返すことはできません。高凝集性、低カップリング。一般的なデータ転送は、フロント エンドが VO をインターフェイス (コントローラー) に転送し、インターフェイスが VO を DTO に変換してサービスに転送し、サービスが DTO を DO に分解し、ドメイン サービスを呼び出してスケジューリングし、逆にVOまたはその他の結果を返し、フロントデスクに転送します。

3. まとめ

一般に、VO、DTO、DO、BO はレイヤード アーキテクチャの異なるオブジェクトであり、各オブジェクトはそれぞれのレイヤーで異なる役割を果たし、それぞれに独自の特性と用途があります。実際の開発では、システムの結合と複雑さを合理的に制御および削減できるように、これらのオブジェクトをビジネス ニーズとアーキテクチャ要件に従って柔軟に使用する必要があります。

おすすめ

転載: blog.csdn.net/weixin_52533007/article/details/126525073