問題タブ [dto]

正規の Customer ドメイン オブジェクトがあるとします。顧客が表示される 3 つの異なる画面があります: 外部管理者、内部管理者、およびアカウントの更新です。

さらに、各画面には Customer オブジェクトに含まれるすべてのデータのサブセットのみが表示されるとします。

問題は、UI が各画面から (たとえば DTO を介して) データを返すときに、完全な Customer ドメイン オブジェクトのサブセットのみが含まれていることです。したがって、Customer オブジェクトを再作成するためにその DTO を Customer Factory に送信すると、Customer の一部しか得られません。

次に、この顧客を顧客リポジトリに送信して保存すると、そこにないため、大量のデータが消去されます。悲劇が起こります。

問題は、この問題にどのように対処するかです。

私のアイデアのいくつか：

• 顧客のどの部分を更新するかを示す引数をリポジトリに含め、他の部分を無視する

• 顧客をロードするときは、静的メモリ、セッション、またはどこにでも保持し、UI から DTO の 1 つを受け取ったら、DTO に関連する部分のみを更新します。

IMO、これらはどちらもクラッジです。他に良いアイデアはありますか？

@chadmyers: ここに問題があります。

エンティティにはプロパティ A、B、C、および D があります。

DTO #1 には、B と C のプロパティが含まれています。

DTO #2 には、C および D のプロパティが含まれています。

UI は DTO #1 を要求します。エンティティをリポジトリから読み込み、DTO #1 に変換し、B と C のみを入力して、UI に渡します。

ここで、UI は B を更新し、DTO を送り返します。エンティティを再作成すると、DTO に含まれているのは B と C だけなので、B と C だけが入力されます。

次に、B と C のみが入力されたエンティティを保存し、A と D を null/空白にします。リポジトリは、A と D を空白として永続的に更新する必要があるかどうか、またはそれらを無視する必要があるかどうかを知る方法がありません。

DB の上にある高度に専門化された DAL があります。アプリは、この DB に対して正しく動作するために、この DAL を使用する必要があります。

生成された DAL (いくつかのカスタム基本クラスに配置されます) には、さまざまな「Rec」クラス (Table1Rec、Table2Rec) があり、それぞれが特定のテーブルのレコード構造を表します。

これがサンプルの疑似クラスです...

各クラスには、各フィールドのプロパティがあります...したがって、次のように記述できます...

フィールドが NULL 値を受け入れることができる場合、値が現在 null であるかどうかを示す追加のプロパティがあります。

したがって....

これが機能するのは、クラスのコンストラクターがすべての NULL プロパティを True に設定し、任意の FieldProperty を設定すると、同等の NullProperty が false に設定されるためです。

私は最近、Web サービスを介して Web 経由で DAL を公開する必要がありました (もちろんこれはセキュリティで保護するつもりです)。「Rec」クラスの構造が Web 経由でそのまま残っていることを発見しました...すべてのロジックは失った..

誰かが前のコードをリモートで実行すると、null を true に設定するクライアント側のコードがないため、どちらの条件も true ではないことに気付くでしょう。

これをすべて間違って設計したような気がしますが、どのように改善すればよいかわかりません。

これを設計する正しい方法は何ですか?

私が現在取り組んでいるプロジェクトには、多くの検索/フィルタリングページが必要です。たとえば、データ、カテゴリ、ユニットなどで問題を取得するための複雑な検索ページがあります。

問題ドメインクラスは複雑で、多くの値オブジェクトと子オブジェクトが含まれています。

。UIの検索/フィルタリング/レポートをどのように処理するのか疑問に思っています。私の知る限り、私には3つの選択肢がありますが、どれも私を幸せにするものではありません。

1.）パラメータをRepository / DAOに送信して、DataTableを取得し、DataTableをUIコントロールにバインドします。たとえば、ASP.NETGridViewに送信します。

このオプションでは、ドメインレイヤーを渡すだけで、指定された仕様のデータベースをクエリできます。そして、完全に構築された複雑なドメインオブジェクトを取得する必要はありません。値オブジェクト、子オブジェクトなどは必要ありません。データベースから直接DataTableのUIに表示するデータを取得し、UIに表示します。

しかし、メソッドの戻り値のようにUIで計算フィールドを表示する必要がある場合は、完全なドメインオブジェクトがないため、データベースでこれを行う必要があります。インテリセンスなどのロジックとDataTableの問題を複製する必要があります...

2.）パラメータをリポジトリ/ DAOに送信してDTOを取得し、DTOをUIコントロールにバインドします。

このオプションは上記と同じですが、検索ページごとに貧血のDTOオブジェクトを作成する必要があります。また、さまざまな問題検索ページについて、問題オブジェクトのさまざまな部分を表示する必要があります。IssueSearchDTO、CompanyIssueTO、MyIssueDTO...。

3.）パラメータをReal Repositoryクラスに送信して、完全に構築されたドメインオブジェクトを取得します。

私はドメイン駆動設計とパターンが好きです。このオプションにはDTOまたは複製ロジックはありませんが、このオプションでは、UIに表示されない多数の子オブジェクトと値オブジェクトを作成する必要があります。また、完全なドメインオブジェクトと針の子のパフォーマンスコストを取得するには、ロットのob結合が必要です。オブジェクトと値オブジェクト。

私はORMツールを使用していません。このバージョンでは手動で遅延読み込みを実装できるかもしれませんが、少しやり過ぎのようです。

どちらが好きですか？それとも私は間違っていますか？これを行うための提案やより良い方法はありますか？

画面 DTO を使用してService LayerとPresentation Layerの間のデータをカプセル化するプロジェクトがあります。この場合、プレゼンテーション層は ASP.Net です。

DTO について知っている唯一のクラスは、サービス層クラスと、これらのサービスを呼び出して DTO を表示するページ/コントロールです。

DTO はほとんどの場合ページ/コントロール固有であるため、プレゼンテーション層に属していると思いますが、DTO を使用するには、サービス層がプレゼンテーション層を参照する必要があることを意味します。

私は、サービス層がより豊富なオブジェクトを返す必要があると考えています (ただし、ドメイン エンティティではありませんか?)。次に、プレゼンテーション層がこれらのオブジェクトを取得し、ページ/コントロールの懸念ごとに非常に具体的な DTO にマップできます。

ここにインターフェイス宣言と DTO があるので、私が話していることがわかります。

編集

ドメイン モデルが関与しないユース ケースを説明する別のコード サンプルを次に示します。多分これは物事を少し明確にするでしょう。DTO の意味を過負荷にしていると思います。私は、ネットワーク上でオブジェクトを転送する機能のための DTO について話しているのではありません。サービス層への通信間の契約を形式化するために DTO を作成しています。

たとえば、私の認証で突然 IP アドレス パラメータが必要になったとします。コントラクト インターフェイスを変更せずに、そのプロパティを DTO に追加できるようになりました。

プレゼンテーション レイヤーにエンティティを渡したくありません。自分のコード ビハインドに移動機能を持たせたくないBlogPost.AddComment(new Comment())

DTO を実装する最良の方法は何ですか?

私の理解では、それらはオブジェクト間でデータを転送する 1 つの方法です。たとえば、ASP.Net アプリでは、DTO を使用してコード ビハインドからビジネス ロジック レイヤー コンポーネントにデータを送信できます。

データをメソッド パラメーターとして送信するだけのような他のオプションはどうでしょうか。(送信するデータが少ない場合、これは最も簡単でしょうか?)

データを保持するだけで、他のオブジェクトから参照できる静的クラス (一種のグローバル アセンブリ データ ストレージ クラス) はどうでしょうか。(これはカプセル化を壊しすぎますか?)

すべての転送に使用される単一の汎用 DTO はどうですか? 使用するのは少し面倒かもしれませんが、操作に必要なクラスの数を減らします (オブジェクトの乱雑さを減らします)。

あなたの考えを共有してくれてありがとう。

DTO

多くのユーザーに拡張したい Web アプリケーションを構築しています。また、Web サービスを介して信頼できるサード パーティに機能を公開する必要があります。

LLBLGen を使用してデータ アクセス レイヤーを生成しています (SQL Server 2008 を使用)。目標は、Web アプリを DAL の詳細から保護するビジネス ロジック層を構築すること、そしてもちろん、DAL を超えた追加レベルの検証を提供することです。また、現時点でわかる限り、Web サービスは基本的に BLL のシン ラッパーになります。

もちろん、DAL には独自のエンティティ オブジェクトのセット (CustomerEntity、ProductEntity など) があります。ただし、これらのオブジェクトには DAL 固有のメソッドが含まれており、アセンブリは DAL に固有であるなどの理由から、プレゼンテーション レイヤーがこれらのオブジェクトに直接アクセスできるようにしたくありません。したがって、アイデアはデータ転送オブジェクト (DTO) を作成することです。アイデアは、これらは本質的に、実際にはデータベース テーブル Customer である CustomerEntity のすべてのフィールドを持ち、おそらく一部の IsChanged/IsDirty プロパティを除いて、他のものではない単純な古い C#/.NET オブジェクトになるということです。したがって、CustomerDTO、ProductDTO などがあります。これらは基本 DTO クラスから継承されると思います。LLBLGen のテンプレートを使用してこれらを生成できると思いますが、まだ確信が持てません。

そのため、BLL はこれらの DTO オブジェクトを受け入れて返すことにより、その機能を公開するという考え方です。Web サービスは、それを使用するサード パーティのためにこれらのオブジェクトを XML に変換することを処理すると思いますが、多くは .NET を使用していない可能性があります (また、JSON を使用して、Web アプリの AJAX 呼び出しからスクリプトを呼び出すことができるものもあります)。

これを設計する最善の方法と、正確にどのように進めるかはわかりません。ここにいくつかの問題があります:

1) これをクライアントにどのように公開する必要があるか (プレゼンテーション層と Web サービス コード)

これらのメソッドを持つ1つのパブリッククラスがあり、すべての呼び出しがアトミック操作になると考えていました:

InsertDTO、UpdateDTO、DeleteDTO、GetProducts、GetProductByCustomer など...

次に、クライアントはこれらのメソッドを呼び出して、適切な引数 (通常は DTO) を渡します。

これは良い、実行可能なアプローチですか？

2) これらのメソッドから何を返すか? 明らかに、Get/Fetch のようなメソッドは DTO を返します。しかし、インサートはどうですか？署名の一部は次のようになります。

ただし、何を挿入するときに何を返す必要がありますか? エラーの通知を受け取りたい。ただし、一部のテーブルには自動インクリメント主キーを使用します (ただし、いくつかのテーブルには、特に多対多の自然キーがあります)。

私が考えた 1 つのオプションは Result クラスでした。

したがって、挿入時に、DTO は get ID (CustomerDTO.CustomerID など) プロパティ セットを取得し、この結果オブジェクトに配置します。クライアントは、Result.Error != null の場合にエラーがあるかどうかを認識し、Result.AffectedObject プロパティから ID を認識します。

これは良いアプローチですか？1 つの問題は、冗長な大量のデータをやり取りしているように見えることです (ID だけの場合)。一部の挿入にはそのような自動インクリメントキーがないため、「int NewID」プロパティを追加してもきれいになるとは思いません。もう 1 つの問題は、Web サービスがこれをうまく処理できるとは思わないということですか? 派生DTOではなく、ResultクラスのAffectedObjectのベースDTOを返すだけだと思います。さまざまな種類の Result オブジェクト (おそらくベースの Result から派生し、Error プロパティを継承する) をたくさん持つことでこれを解決できると思いますが、それはあまりきれいに見えません。

わかりました、これが言い過ぎではないことを願っていますが、明確にしたいと思います。

LINQ オブジェクトを LINQ データ プロバイダーに保持し、IQueryable を返してフィルタリングなどを可能にするために、他の人に似たアプローチを使用しています。他の子オブジェクトで構成される結合テーブル オブジェクト

coreDB.Positions は私の Linq ポジション オブジェクトであり、ユーザー、OrgUnit、およびロールで構成される DTO ポジションを返しています (基になるテーブルは、UserID、RoleID、および OrgUnitID を持つ結合テーブルです)。

私が抱えている問題は、Iqueryable にフィルターを追加しようとすると、DTO.User オブジェクトに使用できる変換がないという SQL エラーが発生することです。

私のGoogleの結果はすべて、生成されたLINQオブジェクトを直接操作している人々のものであるように見えるため、これを解決する方法について完全に途方に暮れています

これを機能させる方法について何か考えがありますか、それともここで何か完全に間違っていますか?

ありがとう

さまざまなビジネス ロジック、アプリケーション層、Web サービス、および WCF コントラクト間で共有される非常に多数の階層構造 (または DTO) があります。すべてのコードをリファクタリングして、構造を個別のビジネス ドメイン領域に分割したいと考えています。

2 つの質問:

1. これを行うのに役立つツールはありますか (クラス A が必要な場合は、すべての依存関係をリストします)。

2. 異なるアプリケーション ドメインで DTO を複製して、それらが独立して進化できるようにするケースはありますか? 固定された正規のビジネス モデルのアイデアは、まったくのフィクションです。

共通のインターフェイスから実装された Domain オブジェクトと DTO オブジェクトで nHibernate を使用しているものはありますか? すべての nHibernate 属性を Domain オブジェクトに分離して、DTO とインターフェイスをきれいにしようとしています。

この問題は、nHibernate がインターフェイスを具体的なクラスに関連付けようとするとエラーをスローすることで発生します。

NHibernate.MappingException: 関連付けがマップされていないクラスを参照しています: IContact

非休止状態のインターフェースの使用について不平を言う理由は理解していますが、それを再構築する方法を視覚化するのに苦労しています。私のコードのスケルトン複製は以下のように設定されています.私のコードをより良く構築する方法についてのアイデアはありますか?

編集：

それらが同じフィールドを保持していることを確認できるように、共通のインターフェイスが必要です (つまり、一貫性を保つためにコンパイラーに依存します)。また、アプリケーションのビュー部分で DTO を使用することもできますが、ビジネスおよびデータ アクセスのために DTO をドメイン オブジェクトにキャストします。また、ICompany の Contacts のタイプが IList ではなく IList であるため、alex のソリューションは機能しません。DTO オブジェクトが Contact Domain オブジェクトを認識しないように、IContact として保持したいと考えています。

これが私の最初の質問です、優しくしてください:)。ある種の分散アーキテクチャを使用したプロジェクトに取り組んでいます。次のことを実行しようとしています。

1. LINQ2SQLを使用するデータアクセス層があります

2. データアクセス層のプロキシであるサービス層があります。

3. エンティティのサービスレイヤーを呼び出すビジネスレイヤーがあります。

   問題は、これらのLINQ2SQLエンティティをビジネスレイヤーに転送するにはどうすればよいですか？

4. これらのオブジェクトをビジネスレイヤーで変更し、サービスレイヤーに戻って、それらをLINQ2SQLエンティティに再変換して、データベースの変更を保持したいと思います。

   私が不可能なことを求めている場合は申し訳ありませんが、私は最善の方法を見つけようとしていますが、私は自分で何かインテリジェントなものを手に入れることができません:)

   よろしくお願いします！