1

ユーザー インターフェイスでドメイン オブジェクトを直接使用する必要があるかどうかはわかりません。たとえば、ユーザー ID、名前、パスワード、および役割のリストを持つドメイン エンティティ ユーザー ユーザーのユーザー インターフェイスを設計したいと考えています。エンティティは、無効な状態にならないように設計されています (無効なパスワードや空のユーザー ID など)。

public class User {
    public User(String userId, String name, String password) {
        //Initialization and validation
    }

    public String getUserId {
        /*implementation*/
    }
    public void changePassword(String oldPassword, String newPassword) {
        /*Set new password if it complies with the rules
        and if the the old one is correct*/
    }

    public void setName(String Name) {
        /*implementation*/
    }
    public String getName() {
        /*implementation*/
    }

    public List<Role> getRoles() {
        /*implementation*/
    }

    public void addRole(Role role) {
        /*implementation*/
    }
}

ユーザー インターフェイスを設計する最も適切な方法は何ですか?

1) ドメイン モデルに固執する: 3 つのウィンドウを設計します。ウィンドウ「新しいユーザー」は、指定されたユーザー ID、名前、およびパスワードで新しいユーザーを作成します。パスワードを変更するための別のウィンドウ「パスワードの変更」と、既存のユーザーの名前と役割を変更できる別の「ユーザーの変更」ウィンドウ

2) 1 つのウィンドウのみを使用して、指定された userId、名前、パスワード、およびロールのリストを持つユーザーを作成することが望ましい場合があります。userId をまだ入力していなくても、ロールを追加できるはずです。

オプション 1 は、ユーザー インターフェイスでドメイン オブジェクトを直接使用できるため、実装が最も簡単です。しかし、ユーザー インターフェースは使いにくいものになる可能性があります。オプション 2 が望ましいですが、ドメイン オブジェクトを直接使用することはできません。ユーザーがまだ作成されていない場合、ロールを追加する方法がわかりません。userId を表す一時的な空のテキスト ボックスなど、その時点で正しい情報がない可能性があるため、ユーザーを作成できません。どうすればこれを達成できますか？

私が考えることができる唯一のクリーンなソリューションは、実際のドメイン オブジェクトの情報を模倣するユーザー インターフェイスで使用するクラスを作成することです。したがって、空のユーザーを作成して役割を追加し、その後で userId を設定できます。ユーザー インターフェイスは、その情報を使用して実際のドメイン オブジェクトを作成できます。

これを回避する簡単な方法はありますか？これは通常どのように管理されていますか？

4

2 に答える 2

1

それは多くの質問ですが、レイヤー間でオブジェクトを渡す方法を検討し始めるときに重要な質問であるため、質問するのは正しいことです。

から始めましょう

「これは通常どのように管理されていますか?」

ドメイン オブジェクトをユーザーに提示する方法は、常に生の形式であるとは限らないことを正しく指摘しました。ユーザーの例のように、ロールの追加がたとえば、2 つのオブジェクトを同時に並べて表示したり、2 つのオブジェクトからの混合データを表示したりします。

ちなみに、わずかな精度：オプション1（複数のウィンドウ）はドメインモデルに固執していると考えていますが、ドメインオブジェクト全体を単一の画面に表示しないため、モデルを模倣する傾向が少ないと思います-しかしそれは詳細です。

では、通常はどのように対処しますか? あなたが言ったように正確に-ビューに合わせて調整されたUI固有のオブジェクトを作成することにより

私が考えることができる唯一のクリーンなソリューションは、実際のドメイン オブジェクトの情報を模倣するユーザー インターフェイスで使用するクラスを作成することです。したがって、空のユーザーを作成して役割を追加し、その後で userId を設定できます。

これらは、DTOや .NET/MVVM の世界では ViewModel オブジェクトなどと呼ばれることがよくあります。

ユーザー インターフェイスは、その情報を使用して実際のドメイン オブジェクトを作成できます。

通常、UI オブジェクトからドメイン オブジェクトを作成/更新することは、UI 自体の責任ではありません。マッピングは別のレイヤーで行われます。

基本的な解決策を見たので、それがどのように異常に管理されているか見てみましょう;)

いくつかの代替手段があります。それらの 1 つは、すべてのユーザー インターフェイスがドメイン オブジェクトの直接表現であるネイキッド オブジェクトパターンです。これにより問題は大幅に簡素化されますが、そのような UI がワークフローと使いやすさの点で常に最高であるかどうかはまだわかりません。

または、プレゼンテーション レイヤーでドメイン オブジェクトを使用するだけで済みます。この最近の投稿では、同じオブジェクトの複数の表現がある場合に発生する問題を指摘し、すべてのレイヤーで同じドメイン オブジェクトを使用する可能性を調べています。ここでの問題は、純粋にドメイン関連ではないデータをドメイン オブジェクトに強制する必要があり、一部の不変条件も放棄する必要がある場合があることです (たとえば、「ユーザーは、少なくともロールがアタッチされていないと存在できません」など)。 "、ユーザーの作成と役割の割り当てのユーザー インターフェイスを分離する場合)。

最後に、ユーザー/ロールの例に戻り、「ユーザーがまだ作成されていない場合、ロールを追加する方法がわかりません」: アプリケーションのエンド ユーザー用に既存の User オブジェクトを用意する必要はありません。役割を選択できる。画面上でロールを選択して、ユーザー オブジェクトの実際のインスタンス化が完了するまで保持し、ID などのすべての必須フィールドを適用することができます。

于 2012-02-12T09:45:38.703 に答える
0

オプション 2 の問題点は何ですか? 最初に新しいユーザー オブジェクトを作成してから、それにルールを追加できます。新しいユーザー オブジェクトを作成するために必要な情報がすべて揃っていない場合 (ユーザー ID テキスト ボックスが空の場合など) は、このフィールドに入力する必要があることをユーザーに通知するだけです。

于 2012-02-11T16:40:38.357 に答える