3

ユーザーと場所の2つのドメインタイプがあります。

LocationRepositoryにメソッドGetUserLocations（）があります。

既存の実装：

var user = UserRepository.GetUser(userId);
var locations = LocationRepository.GetUserLocations(userId);

私にとっては、ユーザータイプからユーザーに関連付けられた場所を取得する方が理にかなっています。

var user = UserRepository.GetUser(userId);
var locations = user.GetLocations();

後者の実装はよりきれいに読み取れると思います。APIクライアントとして、より少ないタイプを処理する必要があります（つまり、LocationRepositoryは必要ありません）。一方、LocationRepositoryに「ファサード」を書き込む必要があるため、維持するコードが増えます。

私は本能に基づいて行動し、 LocationRepositoryのユーザータイプにファサードを作成する必要がありますか、それとも現状に満足し、自分にとって「間違っている」と感じるシーケンス図を使用する必要があります（つまり、位置情報の取得はそのように感じます）間違った「視点」から取得されていますか？

4

2 に答える 2

1

私たちのものを次のようにモデル化することは確かに可能です：

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

たぶん、リポジトリインスタンスは「エンド開発者」に見えてはならず、モデルにカプセル化されるべきではありません。

ただし、に簡単にアクセスできない可能性があるためUniverse.Instance、実際にデータを取得する場所への1つ以上の「エントリポイント」が必要です。

アップデート：

「BingBang」は1つしかないので、現実の世界に近づくので、「リポジトリファサードの入り口」の数をできるだけ少なくすることが目標だと思います。から来て、最終的にすべての既存のデータを生み出しました;-) ...とはいえ、もちろん、今日のシステムは常に大きな妥協点であり、現実の世界をモデル化する能力は限られているため、パフォーマンスがあります影響など...

ただし、具体的な例を示す1つの方法は、次のように、リポジトリを使用して常に新しいデータを取得することです。

LocationRepository.Instance.GetUserLocations(userId);

...一方、次のように、Userモデルクラスを使用して結果をプロパティに保持します。

var locations = myUser.Locations;

このプロパティは、遅延読み込み手法を使用して、最初の要求でLocationRepositoryからデータを読み込み、次に結果を保持します。これにより、場所が1回だけ読み込まれることがわかり、ライブラリを使用する開発者にとって便利になります。次に、LocationRepository.GetUserLocation（userId）をエンド開発者にも表示するかどうかを決定できます。そのルートを進むときは、ある種の暗黙的および明示的な更新メカニズムとライフタイム管理も構築する必要があることに注意してください。

この全体的なアプローチは、私にとって非常に役立つことが証明されています。ただし、Silverlight etálの非同期の世界では、いくつかの新しい警告が追加されています。このようなプロパティは、コードの1行で新しい値と即座に同期して更新できなくなったためです。更新をリクエストするときは、バインディングテクニックを活用するか、コールバックを使用して、更新された値をさらに処理できるようにする必要があります。

全体として、私が信じる最終的な目標は、たとえば、UserRepository新しい単一Userインスタンスを作成してユーザーのストレージに追加し、フィルター処理されたビューを提供する責任がある、たとえば別の通常のドメインタイプと同じように表示することです（クエリ）利用可能なすべてのユーザー。同じ結果への参照を保持するmyUser.Locationsだけでなく、許容されます。myLocations.ByUser["John Doe"]これは、たとえばUserRepository、それを保持する責任がある別のクラスのプロパティである可能性があります。CompanyStaffそのアイデアをさらに推し進めることが、私をそのUniverse.Instanceことに導いたのです。;-)

于 2010-01-22T14:23:06.067 に答える
1

保守性の観点からアプローチします。LocationRepositoryのファサードでそれを行うと、「正しく感じられ」、おそらくコードが少し読みやすくなることに同意します。

あなたが言ったように、トレードオフは維持するためのより多くのコードになるでしょう。しかし、どのくらいのコードについて話しているのでしょうか？それはたくさんあります、そしてあなたはそれを頻繁に更新しなければなりませんか？または、一度書いて忘れて、簡単にユニットテストできるようにすることはできますか？前者の場合は、それを飲み込んで現在の実装を使用し、機能に実際には影響しないことを思い出してください。後者の場合は、その良い感じと他の場所でより読みやすいコードのために努力する価値があるかもしれません。

于 2010-01-22T14:18:06.403 に答える