10

ASP.Net MVC アプリがあり、このアプリ (UI) がビジネス ロジック層 (BLL) を参照し、BLL がデータ アクセス層 (DAL) を参照しているとします。

承認のためにカスタム メンバーシップとロール プロバイダーを利用しています。

メンバーシップ プロバイダーを参照する必要があるレイヤーを特定しようとしています。

MVC では、次の方法で承認チェックを実行できます。

[Authorize(Roles = "SomeRoleName")]
public ActionResult Index()
{
//do something
}

また、私の BLL では、ユーザーがロールに含まれているかどうかを確認することもできます。

public static bool IsRoleEditor(User user, Role userRole)
  {
   bool retValue = false;

   if (user.Application.AppID == UserRole.Application.AppID)
   {
        if (Roles.IsUserInRole("ModifyRoles"))
        {
           retValue = true;
        }


    return retValue;
   }

これを行う場合、両方のレイヤーでメンバーシップ クラスを参照してインスタンス化する必要があります。これは、このようなアプリを設計する正しい方法ですか? 多くの冗長性のようです。

BLL があるので、"[Authorize(Roles = "SomeRoleName")]" 属性の使用を避け、代わりに MVC コード内から BLL 関数を呼び出して、ユーザーがロールに属しているかどうかを確認しますか? これを行う場合、MVC は認証のためにメンバーシップ プロバイダーへの参照を必要とし、ログインやその他の ASP コントロールを利用する必要があります。

基地から離れて間違った方向に進んでいませんか?

4

8 に答える 8

4

私の見解では、これはメンバーシップ/ロール設計の弱点です。

たとえば、分散 n 層アプリの UI 層と BLL 層の両方でロールベースの承認を行うには、関連するビット (GetRolesForUser など) を公開する BLL 層でサービスを公開し、サーバーで RoleProvider を呼び出すことによって実装されます。

次に、BLL によって公開されたサービスを呼び出すことによって実装されるカスタム RoleProvider をクライアントに実装します。

このようにして、UI 層と BLL 層の両方が同じ RoleProvider を共有します。UI 層は、現在のユーザーの役割に関する知識を使用して UI を改善し (たとえば、承認されていない機能に対応する UI コントロールを非表示/無効にする)、BLL は、ユーザーが承認されていないビジネス ロジックを実行できないようにすることができます。

于 2009-09-25T22:18:40.710 に答える
1

素晴らしい質問です。今日も同じことを自問自答しました。私が持っていたアイデアの 1 つ (ただし、それが最善の方法かどうかはよくわかりません) は、アクセスをテストするために BLL に渡すことができるインターフェイス (例: IRoleProvider) を使用することです。

public static bool IsRoleEditor(User user, IRoleProvider rp)
{
     return (rp.IsUserInRole(user,"ModifyRoles"));
}

これにより、BLL でアクセスを検証し、単体テストでモックを使用してロジックをチェックでき、実装する MVC Web サイトでクラスを作成する (またはこれを baseController クラスに実装する) だけで済みます。 IRoleProvider にアクセスし、ASP.NET 認証 API を使用して適切なチェックを行います。

これが役立つことを願っています。

于 2009-09-15T16:38:31.783 に答える
0

MVCのポイントを見逃していませんか？MVCは自然に層に分割されます。モデル（DAL）、コントローラー（BLL）、ビュー（プレゼンテーション）。これらは、必要に応じてさまざまなプロジェクトに組み込むことができますが、コントローラーにはすべてのビジネスロジックがあるため、そこでRoleProviderにアクセスするだけで済みます。

次に、必要に応じて、リポジトリ、パターンなどのパターンを適用してさらに分割します。

デイビー

于 2009-09-26T22:33:54.437 に答える
0

あなたのしていることはいいことだと思います。

承認と認証は、おそらくコントローラーに渡されるサービスレイヤー内に存在する必要があります。

コントローラーがプリンシパルと ID を設定し、MVC 属性を使用してコントローラーでそれを使用する場合、それは良い考えのように思えます。

MVC メンバーシップ プロバイダーをインターフェイスの背後に隠すと、(たとえば) WinForms メンバーシップ プロバイダーと交換して、コントローラーの単体テストを行うことができます。

于 2009-09-28T07:17:40.300 に答える
0

ロールを BLL に渡して、メンバーシップに依存しないようにしてください。または、MartinB が提案したようなインターフェースを使用してください。

利害関係者が別の形式の認証を使用することを決定し、 Roleオブジェクトを使用しなくなった場合、将来どうなりますか?

例：

IsRoleEditor(User user, string[] roles)
{
  return roles.Contains("ModifyRoles");
}
于 2009-09-25T22:02:41.993 に答える
0

User オブジェクトを取得して IPrincipal インターフェイスを実装し、それをレイヤーに投げます。その後、組み込みの [Autorize] 属性を引き続き使用できます。

3 年以上前に城について書かれた記事ですが、この記事が役立つかもしれません。途中で IPrincipal の処理に入り始めます。

HTHS
チャールズ

于 2009-09-11T00:33:17.577 に答える
0

MVC コントローラー 'UI' を呼び出すのは的外れです.MVC の 'C' は、BLL を呼び出すクラスを参照している場合でも、BLL の一部です。しかし、それはあなたの質問のポイントではありません。

この問題は、「'UI' アプリと 'BLL' を 100% 分離するという実際の要件はありますか?」という質問をすることで解決できると思います。両方のコンポーネントがメンバー/ロール プロバイダーへの依存関係を共有している場合は、そのままにして作業を開始します。

BLL を取り外して新しい BLL を接続する場合、おそらく .NET プロバイダーへの依存関係を共有することは問題ありません。それはおそらく問題なく、アプリがバラバラになることはないかもしれません。

上記のジョーの答えは理にかなっていると思いますが...

于 2009-09-28T04:35:09.643 に答える
-1

通常、ロール アクセスは BLL に含めるべきではありません。アクセスは、ユーザー インターフェイスの責任です。

そうは言っても、上記のポスターが述べているように、IPrinciple インターフェイスを活用してください。スレッド レベルで IPrinciple にアクセスできます。

Thread.CurrentPrincipal
于 2009-09-19T12:42:51.507 に答える