同じビジネスオブジェクトに複数のクラスが存在しないようにするにはどうすればよいですか?

Question

多くの場合、ユーザー インデックスのプロパティまたは一部のデータのインデックス セットを持つ Business オブジェクトを使用します。このオブジェクトをフォームまたはその他のビューに表示するときは、ユーザーのフルネームまたはデータのその他のプロパティの一部が必要です。通常、別のクラス myObjectView などを作成します。このケースに対処する最善の方法は何ですか?

さらに明確にするには:問題トラッカーのクラスがあり、問題のクラスにプロパティとして IxCreatedByUser と IxAttachment 値 (添付ファイル レコードのインデックス) のコレクションがある場合。これを Web ページに表示するとき、IxCreatedByUser の代わりに John Doe を表示し、添付ファイルへのリンクとページ上のファイル名を表示したいと考えています。したがって、通常は、Attachment オブジェクトの Collection と CreatedByUserFullName プロパティ、またはそれに類する性質のものを含む新しいクラスを作成します。ページにデータを表示するためにこの 2 番目のクラスを作成するのは間違っているように感じます。もしかしたら私は間違っているでしょうか？

Answer 1

ファサードのパターン。

複数のデータソースの複雑さを抽象化するファサード パターンを作成するというアプローチは、多くの場合適切であり、コードを理解しやすくなると思います。

間接化のレベルが高くなると、コードを読みやすくするという最初の試みが台無しになるため、抽象化のレイヤーを作成しすぎると注意が必要です。特に、他の場所で行ったことに合わせてクラスを作成しているだけだと感じている場合はそうです。たとえば、myLoanView がある場合、システム内のすべてのダイアログに対して myView を作成する必要は必ずしもありません。コードから 10 ステップ戻って、いくつかの場所で使用できる、再利用可能で直感的な抽象化であるファサードを作成してください。

あなたの課題の正確な性質について自由に詳しく説明してください。

Answer 2

重要な原則の 1 つは、各クラスに目的を定義する必要があるということです。「ビジネス オブジェクト」クラスの目的が、ビジネス オブジェクトに関連する関連データを公開することである場合、ルックアップ記述の要求を、それを担当する関連クラスに委任するプロパティをクラス上に作成することは完全に合理的である可能性があります。情報。クラスに固有の書式設定はすべてプロパティで行われます。

Answer 3

この (非常に一般的な、IMO) パターンの処理方法を決定する際に役立つガイドラインをいくつか示します。

1. 必要なのは、頻繁に変更されないルックアップ テーブルへの簡単なリンクだけである場合 (例:州や国の表にリンクする住所の表）、遅延読み込みされたルックアップ テーブルの静的なコピーを保持できます。

2. 表示目的のためだけにロードするために多くの結合やサブクエリが必要となる非常に大きなクラスがある場合は、おそらく上で説明したように、表示目的のために「view」クラスまたは「info」クラスを作成することをお勧めします。XInfo クラス (表示用) が X クラス (編集用) よりも大幅に高速にロードされることを確認してください。このような状況では、データベース側でビューを使用することが非常に良いアイデアになる可能性があります。