3

使ってます

If(User.IsInRole("member"))
{

}

ただし、C＃MVCクラスで機能させることはできません。動作させることができるコントローラーでは使用していないことに注意してください。私は何が欠けていますか？コードはユーザーが何であるかさえ認識しません。

名前空間かもしれないと思いますが、.Mvc他の名前空間と同様に使用しました。

前もって感謝します

4

3 に答える 3

7

HttpContext.Current.User代わりに使用

于 2013-01-10T13:32:32.870 に答える
4

これを行う1つの方法は次のとおりです（結合に関しては正しいですが、単一責任の原則に違反しています）：

if (Roles.IsUserInRole("member"))
{

}

基本的にここでは、web.config のセクションで構成したロール プロバイダーを使用して、現在認証されているユーザーのロールを取得するRoles.IsUserInRole静的メソッドを使用しています。<roles>

しかし、それは私がお勧めするアプローチではありません。ロールやメンバーシップ プロバイダーなどは、Web レイヤーに固有のものである必要があります。ビジネスクラスは、この情報を取得することに煩わされるべきではありません。この情報は、パラメーターとしてそれらに渡す必要があります。

たとえば、このクラスのすべてのメソッドがこの情報を必要とする場合、単純にコンストラクター インジェクションを使用できます。

public class MyClass
{
    private readonly bool _isCurrentUserAMember;
    public MyClass(bool isCurrentUserAMember)
    {
        _isCurrentUserAMember = isCurrentUserAMember;
    }

    public void SomeMethod()
    {
        if (_isCurrentUserAMember)
        {
            // do some business logic for members
        }
        else
        {
            // do some other business logic for non-members
        }
    }
}

ここでわかるように、このクラスが気にしているのは、ビジネス ロジックを実行するために現在のユーザーがメンバーであるかどうかですよね? このクラスは、この情報を取得する方法を気にしません。それはその責任ではなく、クラス内からフェッチを開始すると、クラスがロール情報の取得とビジネスロジックの実行という2つのことを行うため、非常に重要な単一責任の原則に違反しています。

私の推奨するアプローチでは、この責任を呼び出し元のコードに逆にしました。通常、この種のシナリオでは、最初の例で示したようにロール プロバイダーにクエリを実行し、それを基になるクラスに渡すことができる MVC コントローラーになります。

このクラスにさらにメソッドがあり、他のメソッドがこの情報を必要としない場合は、コンストラクター注入を使用する代わりに、ブール値パラメーターを引数としてメソッドに渡すこともできます。

于 2013-01-10T13:37:58.883 に答える