UIの代わりにアクセス制御ロジックを処理するより良い方法はありますか？
私の開発経験のほとんどを通じて、私はさまざまなアクセス制御アーキテクチャーを扱う必要がありませんでした。
それらはすべて非常に簡単です。
Group [Create, Update, Delete]
- User 1
- User 2
Group [Update, Delete]
- User 2
これは、すべての意図と目的のためにうまく機能します。私が抱えている問題は、実際の実装です。私が取り組んだすべてのソリューションは、メニューリンクの表示を許可/拒否したり、ボタンを無効にしたりします。これはすべて、WebAppとWinFormsのどちらのUIであっても、アプリの最上位レイヤーを介して制御されます。
私はかなり大規模なWinFormsシステムの設計の初期段階にいるので、セキュリティアーキテクチャを最初から正しいものにしたいと思います。
（制限されたコントロールを無効にすることによって）ユーザーが特定のアクションを実行することを視覚的に制限することから自分自身が脱出することはないと思いますが、UIでほとんどの作業を行うより良い解決策があると確信しています。
私はそれを理解している（そしてこれらは私の無知によって制限されるかもしれない）ので、これらは私の選択肢です：
- ビジネスレイヤーでユーザー権限を返して検証するロジックを配置する
- Form_loadイベントで、これらのルールを取得し、UI要素を有効/無効にします
- ユーザーにアクションの権限がない場合は、UI要素をそのままにして、ビジネスレイヤー内から操作を停止します（ダーティ！）
確かにこれよりもエレガントな解決策があるはずです。誰かが私に前述のアイデアの代替または改善を提供してくれませんか？
私はそれについて間違って考えていますか？設計中にデータベース設計を再評価する必要がありますか？
WPFは、特定のボタンプレスまたはメニュー項目のロジックを分離コードイベントハンドラーとしてではなくICommandオブジェクトにカプセル化するコマンドパターンの使用を強く推奨しています。これらのオブジェクトの興味深い部分は、標準のExecuteメソッドに加えて、ボタンを有効にするかどうかを決定する標準のCanExecuteメソッドもあることです。このメソッドは、検証ロジックとアクセス許可レイヤーの両方で使用して、UI要素がアクティブかどうかを判断できます。
これにより、パーミッションロジックをビジネスロジックの一部として「サーバー側」にでき、UI要素を手動で移動するのではなく、データバインディングを使用してUI要素の可視性、「有効性」、および機能にリンクできます。それらを有効/無効にします。
これは、MVVMパターンを使用するというWPFの一般的な考え方に適合し、UIとバックエンドビューモデルの間のデータバインディングを使用して、醜い「許可レベルをチェックし、それに応じてボタンのプロパティを設定する」ボイラープレートロジックを非表示にします。
これまでに説明した内容は、使用する必要があるもののほとんどです。 （ごめんなさい）
UIの各主要セクションをモジュール/個別のフォームとして扱うことを検討してください。次に、ビジネスロジックに基づいて特定の子フォームをロードするかどうかを制御するために使用できる親フォームを用意します。
これにより、アクセス制御ロジックをビジネスロジックレイヤー内に維持し、コードビハインドに最小限に依存することができます。この許可チェックの層は、粗いショーに限定される可能性があります。無効にする|非表示タイプの決定。
Winformアプリは制御外のシステムで実行されるため、データベースレイヤーへのインターフェイスを提供するビジネスロジック内で追加のチェックレベルを設定する必要があります。ここで、より細かい権限チェックを適用します。
最後に、可能であれば、Winformsの代わりにWPFの使用を検討してください。 WPFは、winformsがネイティブに提供するものよりも、選択したプレゼンテーションパターン（MVC、MVVM、MVPなど...）を容易にするように構造化されています。 Winformsを使用して安全なアプリを作成することはできますが、少し手間がかかります。
Model View Controllerパターン 、またはそれのわずかなバリエーションを探していると思います。セキュリティに関する限り、ここに詳細があります： https://stackoverflow.com/questions/2543639/design-patterns-for-security-and-data-access-control