プログラミングの産業化レベルの深化に伴い、さまざまなプログラミングモデル（MVC、MVPなど）が際限なく登場し、それらのプログラミングモデルに伴い、多数の新しい概念が押し寄せています。 VOとBOの違いは何ですか、PO、DO、および DTO のようなもので、これらの新しい概念は常に雲の中にありました。インターネット上にはこれらの概念を区別するための記事がたくさんありますが、基本的にはいくつかの同一の記事からの転載であるようで、これらの記事はそれ自体も不明瞭で、いくつかは互いに矛盾しており、一部の記事ではこれらの概念が簡略化されたシステムで使用されているため、人々はますます混乱しています。
何がこの混沌とした状態を引き起こしたのかについては詳しくは述べませんし、その理由を解明するのは難しいと思いますので、
これらの概念そのものをベースにして、その概念を一貫して理解することができれば十分です。この記事の主な目的 目的
専門用語の解説はネット上にたくさんあるので、よく調べてみるとまた割愛しますし、正直言って抽象的すぎて分かりにくいです。誰もが理解できるように、言語（人間の言葉）で説明します。
あまりナンセンスではありません。最初に図を見てみましょう。
この図を読んだ後、ほとんどの人はおそらくすでに直感的に感じているでしょう。この図に直面して、データ間のリンクであるDTO (Data Transfer Object) データ転送オブジェクト
から始めましょう。過去と未来。送信は通常、フロントエンドとバックエンド間の送信を指します。DTOは特別なオブジェクトです。DTO には 2 つの存在形式があります。バックエンドでは、その存在形式は Java オブジェクトであり、これは で定義されているものです。コントローラー (通常はバックエンドにあります) json から java オブジェクトに変換する方法を気にする必要はありません。これはいくつかの成熟したフレームワークによって行われます。たとえば、Spring フレームワークはフロントエンドにあり、その存在形式は次のとおりです。通常は js のオブジェクト (単に json として理解することもできます)、つまり、ajax を通じて要求されたデータ本体です。そのため、2 つのレイヤーにわたって描画されます。
ここで問題になるのですが、マイクロサービスが普及している現在、サービス間で呼び出される転送オブジェクトはDTOと呼べるのでしょうか？
私の理解では、DTO 自体の暗黙の意味は、状況に応じて、
ビジネス モジュールの出力を完全に表現できるということであり、
サービスとサービスが比較的独立していれば、DTO と呼ぶことができます
。サービスは独立しておらず、それぞれが完全なビジネス モジュールではなく、逆アセンブリは計算の複雑さまたはパフォーマンスの問題のみが原因である可能性があります。その場合、これは DTO とは呼べず、BO としか言えません。
VO (Value Object) 値オブジェクト
VO は、表示方法が Web ページ、クライアント、APP を問わず、人に見えるものであれば表示するためのデータであり、VO と呼ばれます
。 VO は js にあります オブジェクト (単純に json として理解することもできます)
VO と DTO の違い
主な違いは 2 つあり、
1 つはフィールドが異なり、VO は必要に応じて一部のフィールドを削除すること、
もう 1 つは値が異なり、VO が DTO の値を説明することです。
簡単な例を挙げると、
DTO は次のようになります。
{
"gender":"男",
"age":35
}
ビジネスワンの場合は性別のみ必要で、古いチャットルームなので男性を直接表示できないため、ビジネス説明の後、ビジネスワンのVOが
{
"gender":"公子"
}
事業2の場合は年齢のみで正確な年齢は必要ありませんので、事業説明後、事業2のVOは
{
"age":"30~39"
}
PO (Persistent Object)
PO の方が分かりやすいです。
簡単に言うと、PO はデータベース内のレコードです。PO のデータ構造はデータベース内のテーブルの構造に対応しています。テーブル内のレコードは PO オブジェクトです。通常、PO は PO オブジェクトです。 , PO での get と set
以外に方法はありません
。PO の場合、その数は比較的固定されており、データベース テーブルの数を超えてはなりません。これは
Entity に相当し、2 つの概念は一貫しています。
BO (ビジネス オブジェクト) ビジネス オブジェクト
BO は、PO の組み合わせです。
たとえば、PO はトランザクション レコードであり、BO は個人のすべてのトランザクション レコードのコレクションです。より
複雑な例では、PO1 はトランザクション レコード、PO2 はログインですレコード、PO3は商品閲覧レコード、PO4はショッピングカート追加レコード、PO5は検索レコード、BOは個人Webサイトの動作オブジェクト、BOはビジネスオブジェクトであり、ビジネスのクラスがBOに相当する
。数に制限はなく、BO には多くのビジネス オペレーションが存在します。つまり、BO には get メソッドと set メソッドに加えて、独自のデータを計算するためのメソッドが多数あります。なぜ BO も 2 つのレイヤーにまたがって描かれているのでしょうか
。その理由は、現在多くの永続層フレームワークがデータ結合の機能を提供しているため、BO はビジネス層で PO を組み立てることによって形成される場合もあれば、クエリを追跡するためにデータベース アクセス層のフレームワークによって直接生成される場合もあるためです
。フレームワークが PO をスキップして BO を直接生成するのは非常に一般的です。PO は追加、削除、変更にのみ使用されます。
BO と DTO の違い
2 つの違いは主にフィールドの削除です
。BO は内部です。ビジネス計算を実行するには、補助データが必要であるか、ビジネスに複数の外部インターフェイスがあります。BO には、そうでないインターフェイスが多数含まれている場合があります。したがって、DTO は、データが必要な限り BO に基づいて、
この関係で外部に提供する必要があります。通常、データの内容は変更されず、内容の変更は BO の内部処理中に完了します。ビジネス上の計算、または説明 VO によって完了
OK、これらの関係は基本的にここで解決されます
待って、DO って何ですか
? タイトルに DO が入っていませんか?
上記の概念は基本的にすべてのプロセスを網羅していますが、DO はそのうちの 1 つの概念だけが同じですが、
どの概念が同じですか? 現在、上記の PO に相当するアリババの開発マニュアルにおける DO (Data Object)の定義と、DDD (Domain-Driven Design) における DO (Domain Object) の主に 2 つのバージョン
があります。上記のBOに相当
最後に、実際の応用について話しましょう。
これらの概念は非常に完成度が高いですが、使用するときはこれに従う必要がありますか?
「もちろんそうではありません。システムの複雑さはシステムとは異なり、連携のレベルも異なります。独断的な必要はありません。
どの概念を使用し、どの概念を保存するかについて、いくつかの実践的な提案をします
。エンティティ、いいえ」何を持っていなければならないかは関係ありません
2、一部のツールシステムとビジネスがあまり複雑でない一部のシステム DTO は BO と 1 つに統合できます。ビジネスが拡大するときは、分割に注意してください。 3、ディスプレイビジネスがそうでない場合は、VO を最初に最適化できます
。複雑です。まったく必要ありません。DTO
4 を直接使用します。これが最も重要でもあります。コンセプトは人々のためのものです。複数の人が共同作業する場合、全員のコンセプトが一貫していることを確認する必要があります。一緒に働く人
公式アカウントに注目し、コミュニケーションをとり、一緒に進歩していきましょう