問題タブ [single-responsibility-principle]

最も単純なASP.NETMVC2コントローラーは、サービスレイヤーを呼び出し、AutoMapperを使用してビューモデルをエンティティにマップします。すべてが素晴らしく見え、繰り返されるコードはありません。

ただし、同様の動作をするシナリオに入ると、単一責任原則（SRP）とDo n't Repeat Yourself（DRY）のバランスを取るのに問題があります。この例としては、一部のプロパティ/動作が共有され、他のプロパティ/動作が特定の車両に固有である車両を追加/編集する必要がある場合があります。

本当に薄いコントローラーを目指して（したがって、単一責任の原則を尊重して）、ビューとコントローラーの両方で、わずかなバリエーション（タイトル、フィールドラベル、フィールドの可視性、ドロップダウン値、選択基準など）でコードを繰り返すことになります。

繰り返されないコードを目指して努力すると、ロジックを1つのコントローラー/ビューにバンドルしすぎて、肥大化してしまいます。

コントローラ/ビューで繰り返されるコードに対処するいくつかの方法は何ですか？リポジトリに分解できるデータベースコードについては話していません。また、サービス層に分解できるビジネスロジックについても話していません。上記のシナリオで最適なソリューションを作成するのに役立つツールや経験則を探しています。

これは私たちのふりかえりの際に出てきたもので、追加のフィードバックとスポット チェックが必要でした。現在、ブール値フラグに基づいて有効/無効にするビューが多数あります (Model.IsNew は一例です)。私は、ビューはできるだけ単純であるべきであり、コントローラーはそのビューのデータを決定するべきであり、必ずしもそれがどのように機能するかではないと考えています。部分的または完全なビューは、何をすべきか、何を表示/非表示にするかを決定するビューに対して処理する必要があると思います。非常に基本的な例は次のようになりますが、これの両方の側面をカバーし、主に私たちが持っているものを反映しています...

コントローラーには、Details と呼ばれる一対のメソッド (post/get) があります。[Get]Details には 1 つのパラメータ Id があり、[Post]Details には id とビューモデルがあります。投稿内では、メソッドは有効なモデルをチェックし、新しいかどうかを判断し、特定の値が変更されたかどうか (リダイレクトをトリガーする) など (これは正しくないと思います) までの 30 行の長さです。[Get]Details で空の ID をチェックし、必要なドロップダウンを設定しますが、特別なことは何もありません (これは正しいと思います)。詳細ビュー自体には、少しのロジックが含まれています: If (!Model.IsNew) { RenderAction(History => History.Show(id); } (これは if 内で間違っていると思います。Show は何を表示するかを知っている必要があります。新しいかどうかに関係なく). これに加えて、詳細ビューのレイアウトが 2 回行われないことです. 詳細/追加はほぼ同じです,

考え、意見、洞察？

nHibernate上に構築されたリポジトリレイヤーを呼び出すASP.NETMVCWebアプリがあるとします。コントローラはISecurityToken、現在のユーザーのIDと権限をカプセル化するリポジトリを渡します。リポジトリは、クエリを実行するときに、ユーザーが表示できるはずの行のみを返すためにそれを使用します。

エンティティ（チケット）を、チケットが割り当てられているユーザーだけでなく、特定のユーザーグループのみが閉じることができるようにしたい。言い換えると、架空のCanCloseTicket()方法には2つの入力が必要です。

1. チケット自体（またはその現在の所有者ID）
2. 現在のユーザーのISecurityToken

この仮説的な方法はどこにあるべきですか？私はいくつかの可能性を見ることができますが、それぞれに欠点があります。

• コントローラ内：コントローラは必要なすべてにアクセスできますが、これによりセキュリティをバイパスできるようになります。（「おっと、falseに設定する前にこのアクションでCanCloseTicket（）を呼び出すのを忘れましticket.IsOpenた！」これは悪臭がします。
• リポジトリ内：リポジトリも両方の部分にアクセスできますが、Ticket.IsClosed上記と同じことが起こらないようにするには、セッターをプライベートにする必要もあります。リポジトリはモデルとはまったく異なるアセンブリに存在するため、内部セッターを使用しても機能しません。代わりに、セッターを公開したままにして、プロパティの現在の値を元の値と比較し、特権のないユーザーがそれを閉じるとエラーを返すことができますが、これも少し臭いがします。repo.CloseTicket()（「おっと、このアクションメソッドでの戻り値を確認するのを忘れました！」）
• チケットの内容：Ticket.Close(ISecurityToken token)エンティティに独自のセキュリティロジックを追加して責任を持たせることは、SRPの違反のように感じます。

ここではリポジトリが最良のオプションだと思いますが、最悪のオプションのように感じます。他に何かありますか？

MVC CMS で使用される画像キャッシュ システムを設計しています。イメージ キャッシャーの主な目的は、イメージを変更することです。拡大縮小、トリミングなどを行い、クライアント サイトにキャッシュします。

データベースと対話する画像キャッシュモデルとマッパーを作成して、画像を追跡し、それらに適用されたアクションの種類 (スケーリング、トリミングなど) を把握します。

モデルとマッパーに加えて、クライアント サイトから渡された引数に基づいてモデルと画像の作成を管理するために API で使用される ImageCacher クラスを作成しました。このクラスは画像を作成し、ビューの画像へのリンクを生成します。 .

同僚は、ロジックの大部分をモデルに入れる必要があるため、この最後のクラスの機能をモデル内に含める必要があると主張しました。

モデルの責任は、データベース レベルでキャッシュされた画像に関する情報を処理することであり、ImageCacher クラスの責任は、キャッシュする URL/画像を作成することであると私は感じているため、私は彼に丁重に同意しません (単一の責任を維持します)。原理）。これに加えて、画像の作成や表示など、プレゼンテーション関連の機能をモデルに含めるべきではないと考えています。

誰かがこれについて何か洞察を持っていますか? このタスクの分割を明確にし、画像キャッシャーを再利用可能にする特定の設計パターンはありますか? モデルにすべてのロジックを追加する必要がありますか?

ありがとうございました。

私のアプリケーションはDIフレームワークを使用しており、必要に応じて「インターフェイスへのプログラム」の慣例に従います。

依存関係を明示的に確認したいので、コンストラクターインジェクションを使用します。しかし、今では私のフォームクラスのコンストラクターが取るパラメーターが多すぎます（> = 4など）。

質問：UIデザインは通常SRPに準拠していないため、Winformクラスにはnコンストラクターの依存関係がある可能性があります。それらをそのままにして、代わりにプロキシオブジェクトを渡し、サービスロケーターを使用しますか...？また、aop-frameworkが使用されていない場合、すべてのコンストラクターに「アスペクト」（ロガーなど）を挿入しますか？

データをフォーマットAからフォーマットBに変換するクラスを作成するときに、「単一責任の原則」に違反しないようにするにはどうすればよいですか。フォーマットAとBの両方の仕様が変更される可能性があるため、このようなクラスが変更される理由は2つあります。

WebFormsを使用して中規模のASP.NETWebアプリケーションを設計/構築しています。プロジェクトの主な作業は各Webフォームの作成であり、コントロールを（コード/データ/データフローの意味で）設計する方法がわかりません。

私が何を扱っているかについていくつか例を挙げて、私が何を意味するのかを理解できるようにします。

アプリケーションでの一般的なタスクは、番地の入力と表示です。そこで、一連のHtmlInputText要素（1行目は1行目、町/市、国、郵便番号など）を含む「AddressFields」というUserControlを作成しました。私のDBエンティティクラスには「Address」というクラスが含まれているため、このコントロールには次のメソッドがあります。

• void ShowAddress（Address addr）-HtmlInputText要素に適切なテキストを入力します）。
• void UpdateAddress（Address addr）-addrの内容をHtmlInputText要素の現在の内容で更新します
• Address CreateAddress（）-Addressの新しいインスタンスを作成し、それをUpdateAddressに渡して、それを返します。

ここまでは順調ですね。これが機能するのは、AddressFieldsコントロールが「ダム」であり、ユーザーにデータを表示して取得するだけだからです。ViewStateもHtmlInputTextフィールドによって直接管理されるため、追加のロジックは必要ありません。

私のアプリケーションのもう1つのエンティティは、Address属性を持つクラスである「Client」ですが、このクラスにはさらに複雑な側面がいくつかあります。たとえば、クライアントには、割り当てることができる一連のタグ（私のアプリケーションでは「カテゴリ」）があります。この場合、ASP.NETCheckboxListコントロールのサブクラスを設計しました。

クライアントの情報（AddressFieldsコントロールを含む）を表示するために必要なすべてのフィールドを含む「ClientFields」という別のUserControlを作成しましたが、「CategoryList」というCheckboxListサブクラスも含まれています。

ここでの問題は、CategoryListコントロールを表示するデータに提供する必要があることです（ただし、ビューステートを使用するため、ポストバックでは提供されません）。この場合、私の質問は次のとおりです。データベースに接続してカテゴリリストを取得するのは誰の責任ですか。

それはCategoryListコントロールですか？（もしそうなら、コントロールのライフスパンのどこでデータベースにクエリを実行しますか？それはClientFieldsが入力された後に発生するため、Control.Loadでは実行できません。ClientFields自体で発生しますか？（ここでも、ライフスパンのどこで発生しますか？ ClientFieldsにはPage.Load内で呼び出されるShowClient（Client c）メソッドがあるため、これは発生します。別の方法は、ClientFieldsからCategoryListを公開して、Pageから直接アクセスできるようにすることですが、これは優れたソフトウェア設計の違反です。

カプセル化、依存性注入、最小知識の原則、そしてあなたはそれを必要としないことによって、「1つのことをする」という部分を理解することができます。しかし、2番目の部分「うまくやる」をどのように理解できますか？

与えられた例は、同じYAGNIの記事で与えられた完全性の概念でした：

たとえば、アイテムの追加、アイテムの削除、またはアイテムの変更を可能にする機能の中で、完全性を使用して「アイテムの名前変更」を推奨することもできます。

しかし、私はそのような推論がフィーチャークリープに簡単に悪用され、「1つのことをする」部分に違反する可能性があることを発見しました。

したがって、機能を確認するためのリトマス試験とは、「うまくいく」カテゴリ（したがって、関数/クラス/プログラムに含める）または他の「1つのことを行う」カテゴリ（したがって、除外する）に属します。 ？

最初の部分である「1つのことを行う」は、UNIXのlsコマンドを介して、出力をフォーマットするための過剰な数のフラグが含まれていることの反例として最もよく理解されます。これは、別の外部プログラムに完全に委任されているはずです。しかし、2番目の部分が「うまくやる」のを見る良い例はありません。

それ以上の機能を削除すると「うまくいかない」という良い例は何ですか？

http://srp.stanford.edu/source/srp-2.1.2.tar.gzから srp-2.1.2 ソースをダウンロードしました。

タイプ: ./configure ---> すべて OK

タイプ: 作る

この時点で、リンク処理中に同じエラーが発生し続けます。以下の最後の行を参照してください。

「tgetent」への参照が見つかりません。それが何を意味するのかわかりません。誰でも私を助けることができますか？

ありがとう