0

MVVM はバインディングとコマンドに基づいています。IsEnabled、IsReadOnly、Visibilityおよびコマンドのバインドが、CanExecuteパーミッションを考慮した GUI の実装に役立つことを理解しています。
しかし、私はこのアプローチに疑問を持っています。

1 つ目は、VM の各 ACL ロジックに関連するプロパティにCanRead|を付ける必要があることです。CanWrite対応するコントロールにバインドできるプロパティ。これは、多くのインフラストラクチャ コーディングとバインディングの XAML タイピングを意味します。理由を説明する動的ツールチップもリストに追加できます。

2 つ目は、XAML での入力ミスにより、特に読み取りアクセス許可に関してセキュリティが損なわれる可能性があることです。コントロールは表示されたままになります。この問題は、ほとんどの場合 (すべてではない)、プロパティにデフォルト値を残す Busines Logic レイヤーによって解決できます。しかし、「帰り」（VM->BL）では、システムは許可されたプロパティのみを気にする必要があります。

セキュリティは分野横断的な懸念事項と呼ばれています。インターセプトを使用した AOP または DI が BL レベルでのセキュリティにどのように役立つかは理解していますが、MVVM 設計パターンのコンテキストで GUI にこれらすべてを実装することについては良い考えがありません。

この問題を解決した経験を教えてください。

4

4 に答える 4

1

私が行ったことは、ViewModel レベルで「フィールド」の概念を作成することでした。これらのフィールドは、基本的に「モデルの各プロパティのプロパティ」を抽象化したものです。

たとえば、「Order」ViewModel のフィールド「OrderNumber」では ReadOnly プロパティが True に設定されており、「Account」ViewModel のフィールド「Name」では Required プロパティが true に設定されています (これはビジネス ロジックというよりもビジネス ロジックに関連したものです)。セキュリティですが、とにかく私はフィールドでこれらの種類のものをカプセル化します)。

次に、XAML を使用するための特別なクラスにいくつかの添付プロパティを作成し、特別なコンテナー (「フィールド エディター」) を作成しました。このコンテナーには、既定のスタイルで、VM 内のこれらのフィールドを指す一連のバインディングが含まれています。コンテナー (実際には ContentControl) は、たとえば、"IsReadOnly" プロパティが変更されたときにビジュアルの子を下に移動し、TextBoxes、ComboBoxes などを読み取り専用状態に設定します (巨大な switch ステートメントを使用するため、コントロールごとに異なるプロパティを設定する必要がある場合があります)。

于 2012-12-30T17:22:50.403 に答える
0

アプリケーションによっては、これがやや難しい場合もありますが、私は通常、Prism モジュールを使用してこの種の問題を解決します。もちろん、Prism を使用していない場合、これはまったく役に立ちません。

たとえば、ユーザーが特定のデータへの読み取り専用アクセス権しか持っていない場合、担当のモジュールにまったく異なるビューをロードします。または、アクセス権がない場合、そのモジュールは何もロードしません。そうすれば、読み取り専用アクセスと読み書きアクセス用に別々のビューを作成できます。

さらに進んでViewModelを交換することもできると思いますが、これを行う必要はありません。

私のアプリでは、ユーザーの Windows 資格情報 (および企業 AD のメンバーシップ ロール) を使用した認証を使用しているため、起動時にこれを処理できることに注意することが重要です。別のログイン/認証システムを使用している場合は、モジュールをロードする前にログインを待機するようにブートストラップを変更する必要があります。

于 2013-01-10T22:39:27.590 に答える
0

私の意見では、MVVM は実際に、今解決した問題を解決する良い方法です。MVVM は実際には UI をコードから分離する問題であるため、UI (ビュー) で好きなように「何でも」実行し、すべてのロジックをモデルに配置できます。これは、コントロール内の特権や「フロー」のようなロジックです。

このようにして、コーダー (設計が不十分な場合が多い) は、コントロールへのロジックを作成できます。たとえば、いつユーザーが保存、削除、開くことができるか、特権を確認したり、デザイナーが知る必要のないものを確認したりできます。また、設計者 (適切なコーディングができないことが多い) は、ユーザーがコントロールをどのように使用できるかを決定できます。ボタン、コンテキストメニュー、またはツールバーから保存する必要があるかどうかと同様です。モデル/ロジックは、設計者が見ることができない独自の DLL に配置することもでき、使用可能なプロパティのみを使用できます。

責任はコーダーに完全にあり、モデルに置かれます。

私にとって、MVVM は「バインディングとコマンドに基づく」ものではありません。バインディングとコマンドは、MVVM 以外のコーディング方法で非常にうまく使用できます。しかし、MVVM はプログラマーにコマンドとバインディングを通常よりも多く使用するように促すため、混乱を招く可能性があることは理解しています。しかし、それだけではありません。それはロジックとUIを分離することであり、あなたが説明するような問題は可能な限り最善の方法で解決されるかもしれません:-)

これは少なくとも、MVVM と権限、およびアクセス制御に関する私の考えです。

あなたの質問を完全に誤解していないことを願っています。

于 2012-12-30T20:25:57.943 に答える
0

私の意見と経験では、UI を使用してセキュリティを強化することは決してすべきではなく、単にビジネス ロジック (BL) に従って、できることとできないことをユーザーに提示するだけです。これにより、侵害の原因となる XAML の入力ミスの問題が防止されます。さらに、ユーザーが実行したいことを UI に実行させるために、約 10 億個のユーティリティとハッキングが存在します。

例:
http://newtipstrik.wordpress.com/2012/02/06/win-enabler/
http://snoopwpf.codeplex.com/

要約すると、はい、UI は、セキュリティ コンテキストのすべてまたは一部を実装するのではなく、セキュリティ コンテキストを「認識」する必要があります。

于 2013-01-16T15:54:34.067 に答える