2

[申し訳ありませんが、作品は所有権があるため、オブジェクトの詳細を示すことはできません]

私は同僚と一緒に Java アプリケーションに取り組んでいます。私はクライアント側を担当しており、彼はサーバーコードを書いています。

アプリケーションは、X オブジェクトのテーブルを表示します。表の列は、X の属性の一部を示しています。さらに、各 X の Y の数を示す列があります (関連付けは Y から X への多対 1 であり、Y はその親 X への参照を持ちます)。

Y のカウントは X の属性ではなく、DB のクエリを介して取得されます。

私は TableModel を使用しているので、テーブルのモデルとして X オブジェクトを使用する方が明らかに簡単です。しかし、Y カウントは XI の属性ではないため、X とカウントを保持するコンテナ オブジェクトを作成する必要があります。これは、不要と思われるクラスを追加するため、かなり面倒です。

私は同僚に、X に追加のフィールドとゲッターを追加するよう提案しました。

プライベート void マップ情報 = 新しい HashMap();

これにより、モデル オブジェクト X がより柔軟になります。X の性質に固有のモデルの主要な属性に影響を与えることなく、いつでも必要な状態をクライアントに格納できます。キーはクライアントでのみ定義されるため、モデルが汚染されることはありません。

モデル オブジェクトはドメインのみをモデル化する必要があり、余分なフィールドはドメイン オブジェクトに関連していないため、追加すべきではないと感じたため、彼は拒否しました。彼は、クライアントがこれを処理する必要があると考えています。

どちらの視点にもメリットがあるように思われるので、他の読者がこれについてどう思うか、または感じているかに興味があります。

ありがとう、

ティム

4

3 に答える 3

3

データベース モデルと MVC のモデルを混同していると思います。MVC パターンはプレゼンテーション レイヤーの設計パターンであることに注意してください。モデル、つまり MVC では、単純なアプリケーションではデータベース モデル (データベース内のエンティティ) にすることができますが、それは必須ではありません。

あなたが言ったように、テーブルに表示しているフィールドを含める必要がある別のクラス（テーブルモデル）が必要だと思います。このモデルは、ビジネス ロジック レイヤーから取り込まれます。つまり、BLL の出力である必要があります。これを DTO (データ転送オブジェクト) と呼ぶこともできます。アイデアは、必要なデータだけを持つことです。カウントが必要な場合は、すべての Y ではなく、DTO にカウントのみを含めます。これにより、アプリケーションが管理しやすくなるだけでなく、レイヤー間でのデータ転送が減少するため、アプリケーションのメモリ フットプリントが減少し、増加します。パフォーマンスも。

于 2010-09-14T09:11:12.877 に答える
1

私はまったく同じ立場にあり (私は主にサーバー側の担当者です)、あなたの同僚のように見えます。

この場合、サーバー側は Web サービスです。将来誰がこのサービスを呼び出すかはわからないので、できるだけ一般的なものにしておきたいと思います。モデルに特別なデータが必要なときはいつでも、適切なクラスを拡張してこの方法で追加します。いずれにせよサブクラス化する必要があるため、多くの場合、これは非常に簡単です (たとえばPropertyChangeSupport、MVC の多くのクラスで必要です)。

ただし、これが「カウント」の例を解決するかどうかはわかりません。同様の状況にも遭遇し、user446612がデータを保持することを示唆しているように、特別な DTO を作成しました。

于 2010-09-14T09:16:08.973 に答える
0

返信ありがとうございます。

ティング氏は次のように述べています。

データベースモデルとMVCのモデルを混同していると思います

はいはい。事実上 2 つの異なるモデル オブジェクトがあり、1 つはデータベース用で、もう 1 つはクライアント アプリケーションの MVC の M 用であり、クライアント側モデルは、取得されたデータベース モデル オブジェクトから BLL によって設定されるということですか?

私の読みではmusiKkも同じことを言っています。

クライアントのデータ モデル (MVC M) としてサーバー側モデルを使用しており、オブジェクトはシンプルです。

MusiKk は次の理由を挙げています。

将来誰がこのサービスを呼び出すかはわからないので、できるだけ一般的なものにしておきたいと思います。

これはまさに私の同僚が提唱した議論です。これが不可欠であることに完全に同意します。ただし、ここでの私の考えは、オブジェクトのマップをモデルに追加しても、モデルの一般性が低下することは決してないということでした。これはクライアントの便宜のために提供され、空のマップです。

利点は次のとおりです。

(1) クライアントがサブクラスを作成したり、単一の追加フィールドを持つこのような単純なケースで新しいオブジェクトを作成したりする必要がなくなります

(2) 一時的な状態は、クライアントで使用されるオブジェクトにカプセル化できるため、非常に柔軟です。

欠点は次のとおりです。

(1) オブジェクトが大きくなるため、ネットワーク上を移動するときにオブジェクトが大きくなります

（2）サブクラス化すると、使用しなくても余分なフィールドがあります

于 2010-09-14T09:49:29.507 に答える