問題タブ [separation-of-concerns]

何かがビューまたはコントローラーに入るかどうかをどのように判断しますか?

以下に具体的な例をいくつか示します。

• Zend_Captcha: コントローラがキャプチャを生成してビューに渡しますか、それともビューがキャプチャを生成しますか?
• Zend_Alc: ビューのセグメントをユーザーに表示するかどうかをビューが決定しますか?それとも、使用可能なアクションに応じて複数のビューがあり、コントローラーが表示に適したビューを選択しますか?
• Zend_Session: ビューは、セッション データに基づいてビューを表示しているユーザーを追跡しますか?それとも、コントローラーによって解析され、何らかのパラメーターとしてビューに提示されますか?

どのコンポーネント (モデル、ビュー、またはコントローラー) が何をすべきかについてのルールまたはガイドラインは、私が見ることができる場所に書かれていますか? Zend Framework サイトのドキュメントにはそれがありませんでした。

次のシナリオを想像してみてください。コントロール A とコントロール B を含む Page1 があります。

コントロール A にボタンがあり、このボタンをクリックすると、コントロール B が反応するとします。しかし、これを抽象的な方法で行いたいと考えています。つまり、コントロール A について何も知らないコントロール B を持つことはできず、その逆も同様です。

そうすれば、これらのコントロールを分離して開発し、単体テストによってそれらを駆動できます。

今、私は解決策を持っていると思いました。皆さんがそれについてどう思うか知りたいだけです.

コントロール A のボタン クリックで、セッションに「メッセージ」を配置します。つまり、Session["MESSAGES"] = "ControlA_Click" です。

Page1 の Page_LoadComplete() で、次のように ProcessMessages を呼び出します。

ControlB の ProcessMessage() メソッドでは、次のように、ControlB が関心のあるメッセージに反応できます。

私には、これはうまくいくようです。これにより、これらのコントロールを互いに完全に個別に開発できますが、抽象レベルでのコントロール間の通信も可能です。

このクラッシュを引き起こす可能性があると私が考えることができる唯一のことは、おそらくページとユーザー コントロールに関連する ASP.NET ライフサイクルです。私がそれを理解する方法は、所有するページで Page_LoadComplete() が呼び出される前に、すべてのイベントがコントロールで処理されている必要があるということです。

考え？

階層化されたアプリケーションがあるか、少なくとも階層化されたアプリケーションに移行中です。次のように分類されます。

• インターフェイス (ユーザー インターフェイスまたはアプリケーション インターフェイス、つまり Web サービスなど)
• ビジネスの論理
• データアクセス

この質問の残りの部分をより具体的にするために、特定のインスタンスについて説明します。

ユーザー インターフェイスがあり、その背後にコントローラー オブジェクト (ビジネス ロジック層) があります。このコントローラーは、別のオブジェクト (データ アクセス層) を介してデータベースと通信します。

特定のコンテキストでは、ユーザー インターフェイスを使用して、実行中の操作を関連付ける従業員をユーザーが選択できます。ユーザーが選択できる従業員に関するルールがあるため (実際には、コントローラーの外にあるすべての世界)、コントローラーはこれに対して 2 つのことを提供します。

• 選択可能な従業員のリストを含む読み取り可能なプロパティ
• 現在選択されている従業員を含む読み取り/書き込み可能なプロパティ

ユーザー インターフェイスはリストを読み取り、それを使用してコンボボックスに入力する場合があります。

このアプリケーションのバージョン 1 では、コンボボックスに従業員の識別番号と従業員の名前が含まれています。

すべては順調です...

... バージョン 1.1 まで、バグ修正。ユーザーは、ジミー オルソンとジミー オルソンのどちらかを簡単に判別できないため、ジミー オルソンとジミー オルソンのどちらかを選択できないと不満を漏らしています。彼は、ジミーが営業部門に 1 人、開発部門にもう 1 人いることを知っているので、この 1.1 バージョンの修正は、コンボボックスにスラッシュと部門名を追加するだけです。バージョン 2 では、コンボボックスを列をサポートするコンボボックスに置き換え、スラッシュを削除することを選択しましたが、1.1 では、さらなるバグのリスクを最小限に抑えるためにこれが選択されています。

つまり、コンボボックスには次のものが含まれます。

• 1 - ジミー・オルソン/セールス
• 2 - ジミー・オルソン/開発
• • 他の人

ただし、ユーザー インターフェイス コードには SQL コードや、その部門を把握する方法がないため、コントローラーに移動してそこでコードを確認する必要があります。コントローラーには部門は必要ありません。正直なところ、従業員の名前も必要ありません。識別番号だけで十分です。コントローラーには、部門に要求したり、何かをしたりするものは何もありません。そのため、データ アクセス レイヤーに降りて、そこで SQL を変更する必要があります。

この解決策は率直に言ってにおいがします。

このコントローラーに複数のインターフェイスがあり、要件が異なる場合、3 つの解決策が考えられます。

1. データ アクセス レイヤーを変更して、複数のインターフェイス (2 レイヤー離れた) の (増加/多様な) ニーズに対応します。これは、すべてのインターフェイスが必要なすべてのデータを取得する可能性があることを意味します。他のインターフェースの
2. ユーザー インターフェイスがデータ アクセス レイヤー (まだ 2 レイヤー離れている) に必要なものを通知できるようにするものを追加します。
3. 関係するコントローラーまたはアクセス層を変更せずに、何らかの方法でユーザー インターフェイス層が必要なデータを取得できるようにします。

上記の解決策はどれも気分が良くありません。

私が疑問に思っているのは、私たちは完全にコースから外れているのでしょうか? これをどのように行いますか？上記の 3 つの下に 4 つ目と 5 つ目の解決策はありますか?

この質問: Separation of Concerns に従って、受け入れられた回答には次の引用が含まれています。

関心の分離は、これらの関心のそれぞれのコードを別々に保つことです。インターフェイスを変更しても、ビジネス ロジック コードを変更する必要はありません。

これは単に、コントローラー/データ アクセス レイヤーが提供する必要があるのは、その仕事を行うために必要なもの (つまり、従業員の識別番号) だけであり、ユーザー インターフェイスがデータベースと通信して詳細情報を要求する必要があることを意味するだけですか?これらの特定の従業員について？

レイヤー間を適切に分離して Web アプリを設計するために最善を尽くしています。私はリポジトリ パターンを使用しているため、Web フロント エンドによって呼び出される ObjectService によって呼び出される SQLObjectRepository があります。

私のオブジェクト モデルでは、ユーザーは 1 つ以上の領域に関連付けられており、アクセスできるオブジェクトをフィルター処理する必要があります。私の質問は、オブジェクトのクエリを実行するときに、コードをサービスに配置してオブジェクトのアクセス許可を設定するか、またはそのコードをリポジトリに配置する必要があるかということです。ユーザーが 2 つの地域のメンバーである場合、ユーザーをパラメーターとしてサービスに渡す必要がありますか、それともユーザーの地域をサービスに渡す必要がありますか?

GUI を追加するコマンドライン インターフェイスを備えた既存のアプリがあります。あるクラスから継承したオブジェクトのリストがあり、それをリストに表示する必要があるのに、サブクラスごとに表示方法が少し異なるという状況がよく発生します。

リフレクション/RTTI を使用して表示を行う巨大な switch ステートメントをどこにでも持ちたくないので、各クラスは、リストに表示される独自の要約文字列を返す方法を知っています。

さまざまなコンテキストでさまざまな情報を表示するために、同様の関数があります。GUI の追加が必要になるまでは、これで問題ありませんでした。文字列だけでは不十分です。グラフィック コントロールを作成する必要があります。

GUI で表示できるようにするためにすべてのクラスを変更する必要はありません。特に、これを移動したい GUI プラットフォームが少なくとも 1 つあるためです。

RTTI や switch ステートメントに頼らずに、この GUI コードをデータ オブジェクトから分離するために使用できるテクニックはありますか? GetSummary関数も取り出せるといいですね。

理想的には、データ クラスを取り、コンパイル時の型ではなく実行時の型に基づいて表示できる表示クラスの階層を持つことができます。

この質問は言語に依存しませんが、私は C# 派なので、POCO という用語を使用して、通常はゲッター フィールドとセッター フィールドを使用して、データ ストレージのみを実行するオブジェクトを意味します。

ドメイン モデルを作り直して超強力な POCO にしましたが、プロパティ値がドメイン内で意味をなすようにする方法に関していくつかの懸念が残っています。

たとえば、サービスの EndDate は、サービスが下にある契約の EndDate を超えてはなりません。ただし、チェックを Service.EndDate セッターに入れるのは SOLID 違反のように思えます。実行する必要がある検証の数が増えると、私の POCO クラスが雑然とすることは言うまでもありません。

私にはいくつかの解決策があります（回答に投稿します）が、それらには欠点があり、このジレンマを解決するためのお気に入りのアプローチは何ですか?

悪意のあるデータセットしかなく、Microsoft アプリケーションがレイヤー間の転送オブジェクトをブロックする場合、データセット/データテーブルまたは DTO/POCO のいずれかになります。私は、DTO/POCO を使用するのが好きなギャングに属しています。

SubSonic、Entity Framework、NHibernate などのマッピング レイヤーのこの突然の波で、お気に入りの POCO を引き続き使用する必要がありますか?? 私はほとんどこれを行い、ASP.net Web フォームを操作するとき、99% の時間は、コントロールと各タイプに固有の機能にバインドするために ObjectDataSource を使用することになります。

この POCO への愛をあきらめて、IQueryables や Entities などを渡し、他の DataSource オブジェクトを利用する必要がありますか??

DTO の代わりにこれらのオブジェクトを使用することの長所と短所は何ですか?? アプリのデザインとパフォーマンスにどのような影響がありますか?

編集:Linq Datasorce や Entity データソースなどの他のデータソースを使用できるようになるのはいつですか?

過去に、ドメインとビューに同じモデル オブジェクトを再利用すべきではないというモデルに関する MVC のアドバイスを読みました。しかし、なぜこれが悪いのかを議論してくれる人を見つけることができませんでした.

ドメイン用とビュー用の 2 つの別個のモデルを作成し、それらの間でマッピングを行うと、多くの重複と、退屈なマッピング コード (一部はAutoMapperなどによって軽減される可能性があります)が作成されるというのが私の意見です。エラーが発生しやすくなります。

2 つの懸念事項に対して個別のモデルを用意することで、コードの重複とマッピングの問題を解決する価値があるのはなぜでしょうか?

このクラスをリファクタリングする必要があると思いますか。（関心の分離に関して）

ReadMappingFromAttributes-タイプTからマッピングを読み取り、クラスに格納します。使用するリストの名前と、値を設定するプロパティの名前とcsvcolumnsの名前を含むいくつかのcsvMappingColumnsがあります。

GetObjectsFromList-CVSListreader（コンストラクターを介して渡される）を使用して、すべての行からKeyValuePair（Key = csvcolumnName、value = actual value）としてデータを取得し、その後、mappinginformation（listnameおよびcsvMappingColumns）を使用してデータを設定します。オブジェクト。

このクラスに2つの懸念があるのか​​1つあるのか判断できません。最初に、2つあると感じ、行からオブジェクト、別のオブジェクトへの変換をリファクタリングし始めました。しかし、この後、最初にmappingretriverを作成する必要があったため、この機能を使用するのは厄介でした。その後、行を取得し、マッピングと一緒に「マッパー」に渡して、オブジェクトを行から変換する必要がありました。

/ w

私は DDD とそれが MVC にどのように関係するかについて頭を悩ませようとしていますが、エンティティの識別に関しては問題があります。

特に、プレゼンテーション、ドメイン、およびデータ モデルを厳密に分離するようにしています。ここでの問題は、これらの境界を越えてエンティティの識別を保持する方法にあります。明確にするために、異なるコンテキストで同じエンティティを表すために別々のクラスを使用しています。 「shipment_request」データベース テーブル (私のデータ モデル)。

「ID」プロパティ (ShipmentRequestId など) を使用すると、達成しようとしている分離に違反するように感じます。この ID プロパティはデータベースの問題であり、ドメインの問題ではないためです。レイヤー間で同じオブジェクトを渡したくありません。これは、不要なデータをプレゼンテーションレイヤーに渡すことを意味するためです。

この分離を維持しながら、これらのレイヤー間のアイデンティティを追跡するにはどうすればよいでしょうか?