タグ付けされた質問 「dto」

私のシナリオは次のとおりです。 さまざまな種類のセンサーからデータを受信し、後でさまざまなフロントエンドおよび分析サービスで使用できるように変換して保持するように設計されたシステムを設計しています。 私はすべてのサービスを可能な限り独立したものにしようとしていますが、問題があります。チームは、使用したいDTOを決定しました。外向きサービス（センサーデータ受信者）は、独自の方法でデータを受信し、JSONオブジェクト（DTO）に変換して、メッセージブローカーに送信します。メッセージのコンシューマーは、センサーデータメッセージの読み取り方法を正確に知ることができます。 問題は、いくつかの異なるサービスで同じDTOを使用していることです。更新プログラムは複数の場所に実装する必要があります。明らかに、ここでDTOのいくつかの余分なフィールドや不足しているフィールドを設計しました。サービスが更新されるまで問題はあまりありませんが、それでも私を悩ませ、気分が良くなります。間違いを犯す。簡単に頭痛になります。 システムを間違って設計しようとしていますか？そうでない場合、これを回避する方法は何ですか、または少なくとも私の心配を緩和するために？

33 architecture  microservices  architectural-patterns  dto  pubsub 

私はRCPアプリケーションに取り組んでいます。このアプリケーションは初めてです。 Spring Beanは、エンティティを保存/取得するビジネスロジックを記述するために使用されます。 ただし、エンティティを直接クライアントに送信する代わりに、DTOに変換してクライアントにデータを入力しています。保存中に、再びDTOをエンティティに変換して保存します。 これらの変換の利点は何ですか？誰か説明できますか？

18 java  spring  entity  map  dto 

TL; DR-サービス間でPOJOライブラリを共有しても大丈夫ですか？ 一般的に、可能な場合は、サービス間の共有を厳密に制限します。データを共有しているサービスが、クライアントが使用するクライアントライブラリを提供するかどうかについては、いくつかの議論がありました。client-libは通常、サービスのクライアントが使用するオプションであり、client-libを使用するか、代替言語を使用してライブラリなどの一般的な側面を使用するかを問わず、APIを消費できます。 私の場合、データのオブジェクトを作成するサービスを検討しています。このオブジェクトがPETであると仮定しましょう。これはデータベースエンティティではなく、厳密に基になるデータを暗黙的に表すPOJOです。このPOJOは、APIが定義したものです。想定：ペット-年齢、体重、名前、所有者、住所、種など サービス1 -PetKeeper：何らかの理由でペットを生成し、すべてのデータを保持し、このサービスを参照してペットを取得するか、ペットに変更を加え、名前の変更または住所の変更を行う必要がありますこのサービスへのAPI呼び出し。 サービス2 -PetAccessor：このサービスはペットを収集し、検証チェックを行います サービス3,4-より多くの中間サービス呼び出し サービス5-ユーザーインターフェイス これらは非常にarbitrary意的ですが、ポイントは簡単です。UIまたはユーザー向けのサービスは、何らかの方法でこの「PET」オブジェクトを提示したいと考えています。APIを介してサービスを呼び出す必要があります。サービスは、サービスを呼び出し、サービスを呼び出すなど、必要な情報を収集してリレーバックを開始するサービスに到達するまで呼び出します。最後に、UIサービスには表示するPETオブジェクトがあります。 これは非常に一般的ですが、絶対的な考え方で、すべてのサービスでPETオブジェクトを複製しました。DRY（繰り返さないでください）の原則は、サービス内のコードにのみ適用され、サービス全体には適用されませんが、ポイントはまだあります。フィールドを追加したらどうなりますか...それぞれのPOJOの5つのサービスを変更する必要があります。 -または-APIからのpojoの一部を含むPet-Objects-Libraryを提供できます。各サービスはライブラリにインポート/依存できます。サービス自体への依存関係はありませんが、一般的なライブラリのみに依存しています。各サービスが同じタイプのオブジェクトを持ち、更新が簡単になるように、私はこのアイデアが好きです。しかし、私はGod-Objectsを心配しています。 賛否両論-最適な設計は何ですか？同じPOJOクラスの繰り返しを最小限に抑えながら分離されたままにするために、サービス間でデータを渡すために何をしましたか？

15 java  dto  microservices 

単一ページアプリケーションにREST APIを提供するASP.NET Web APIがあります。DTO / POCOを使用して、このAPIを介してデータを渡します。 問題は、これらのDTOが時間とともに大きくなっていることです。そのため、DTOをリファクタリングしたいと考えています。 DTOを設計する「ベストプラクティス」を探しています。現在、値型フィールドのみで構成される小さなDTOがあります。 public class UserDto { public int Id { get; set; } public string Name { get; set; } } 他のDTOは、構成によってこのUserDtoを使用します。例： public class TaskDto { public int Id { get; set; } public UserDto AssignedTo { get; set; } } また、他から継承することによって定義される拡張DTOがいくつかあります。たとえば： public class …

13 rest  api-design  web-api  dto  poco 

彼の本「Clean Architecture」で、叔父ボブは、プレゼンターが受け取ったデータを「表示モデル」と呼ぶものに入れるべきだと言っています。 これは、Model-View-ViewModel（MVVM）設計パターンの「ViewModel」と同じものですか、それとも単純なデータ転送オブジェクト（DTO）ですか？ 単純なDTO ではない場合、ビューにどのように関連しますか？ビューは、オブザーバー関係を通じて更新されますか？ 私の推測では、彼の本の第23章でロバート・マーティンは次のように述べているため、MVVMのViewModelに似ていると思います。 [The Presenter's]ジョブは、アプリケーションからデータを受け取り、プレゼンテーション用にフォーマットして、Viewがデータを画面に簡単に移動できるようにすることです。たとえば、アプリケーションでフィールドに日付を表​​示する場合、プレゼンターにDateオブジェクトを渡します。プレゼンターは、そのデータを適切な文字列にフォーマットし、Viewモデルと呼ばれる単純なデータ構造に配置します。Viewモデルでは、データを見つけることができます。 これは、たとえばDTOの場合のように、単に関数引数として受け取るのではなく、Viewが何らかの方法でViewModelに接続されていることを意味します。 あなたは、画像を見れば、プレゼンターはビューモデルを使用しますが、ので、私はこれを考えるもう一つの理由はありませんビューを。一方、プレゼンターは出力境界と出力データDTOの両方を使用します。 DTOでもMVVMのViewModelでもない場合は、それが何であるかを詳しく説明してください。

13 architecture  mvvm  dto  plugin-architecture  view 

たとえば、クラスには通常、クラスのメンバーとメソッドがあります。例： public class Cat{ private String name; private int weight; private Image image; public void printInfo(){ System.out.println("Name:"+this.name+",weight:"+this.weight); } public void draw(){ //some draw code which uses this.image } } しかし、単一責任の原則とオープンクローズの原則について読んだ後、クラスをDTOと静的メソッドのみのヘルパークラスに分離することを好みます。例： public class CatData{ public String name; public int weight; public Image image; } public class CatMethods{ public static void printInfo(Cat …

10 object-oriented  static-methods  dto