階層化されたアプリケーションがあるか、少なくとも階層化されたアプリケーションに移行中です。次のように分類されます。
- インターフェイス (ユーザー インターフェイスまたはアプリケーション インターフェイス、つまり Web サービスなど)
- ビジネスの論理
- データアクセス
この質問の残りの部分をより具体的にするために、特定のインスタンスについて説明します。
ユーザー インターフェイスがあり、その背後にコントローラー オブジェクト (ビジネス ロジック層) があります。このコントローラーは、別のオブジェクト (データ アクセス層) を介してデータベースと通信します。
特定のコンテキストでは、ユーザー インターフェイスを使用して、実行中の操作を関連付ける従業員をユーザーが選択できます。ユーザーが選択できる従業員に関するルールがあるため (実際には、コントローラーの外にあるすべての世界)、コントローラーはこれに対して 2 つのことを提供します。
- 選択可能な従業員のリストを含む読み取り可能なプロパティ
- 現在選択されている従業員を含む読み取り/書き込み可能なプロパティ
ユーザー インターフェイスはリストを読み取り、それを使用してコンボボックスに入力する場合があります。
このアプリケーションのバージョン 1 では、コンボボックスに従業員の識別番号と従業員の名前が含まれています。
すべては順調です...
... バージョン 1.1 まで、バグ修正。ユーザーは、ジミー オルソンとジミー オルソンのどちらかを簡単に判別できないため、ジミー オルソンとジミー オルソンのどちらかを選択できないと不満を漏らしています。彼は、ジミーが営業部門に 1 人、開発部門にもう 1 人いることを知っているので、この 1.1 バージョンの修正は、コンボボックスにスラッシュと部門名を追加するだけです。バージョン 2 では、コンボボックスを列をサポートするコンボボックスに置き換え、スラッシュを削除することを選択しましたが、1.1 では、さらなるバグのリスクを最小限に抑えるためにこれが選択されています。
つまり、コンボボックスには次のものが含まれます。
- 1 - ジミー・オルソン/セールス
- 2 - ジミー・オルソン/開発
- 他の人
ただし、ユーザー インターフェイス コードには SQL コードや、その部門を把握する方法がないため、コントローラーに移動してそこでコードを確認する必要があります。コントローラーには部門は必要ありません。正直なところ、従業員の名前も必要ありません。識別番号だけで十分です。コントローラーには、部門に要求したり、何かをしたりするものは何もありません。そのため、データ アクセス レイヤーに降りて、そこで SQL を変更する必要があります。
この解決策は率直に言ってにおいがします。
このコントローラーに複数のインターフェイスがあり、要件が異なる場合、3 つの解決策が考えられます。
- データ アクセス レイヤーを変更して、複数のインターフェイス (2 レイヤー離れた) の (増加/多様な) ニーズに対応します。これは、すべてのインターフェイスが必要なすべてのデータを取得する可能性があることを意味します。他のインターフェースの
- ユーザー インターフェイスがデータ アクセス レイヤー (まだ 2 レイヤー離れている) に必要なものを通知できるようにするものを追加します。
- 関係するコントローラーまたはアクセス層を変更せずに、何らかの方法でユーザー インターフェイス層が必要なデータを取得できるようにします。
上記の解決策はどれも気分が良くありません。
私が疑問に思っているのは、私たちは完全にコースから外れているのでしょうか? これをどのように行いますか？上記の 3 つの下に 4 つ目と 5 つ目の解決策はありますか?
この質問: Separation of Concerns に従って、受け入れられた回答には次の引用が含まれています。
関心の分離は、これらの関心のそれぞれのコードを別々に保つことです。インターフェイスを変更しても、ビジネス ロジック コードを変更する必要はありません。
これは単に、コントローラー/データ アクセス レイヤーが提供する必要があるのは、その仕事を行うために必要なもの (つまり、従業員の識別番号) だけであり、ユーザー インターフェイスがデータベースと通信して詳細情報を要求する必要があることを意味するだけですか?これらの特定の従業員について？