2011-12-08 11 views
0

私の質問への回答を得るために長い間、 "私はカスタムMembershipProvider実装を書くべきか、自分のカスタムシステムを作るべきですか?"だから、私はMembershipProviderのやり方を見て、メンバーシッププロバイダの作成を開始するのはそれほど悪くないと決めました。しかし、当時私は何か問題を感じています。カスタムメンバーシッププロバイダは、本当に価値のあるものですか?

たとえば、私のシステムにはユーザー名はありません。電子メールはユーザー名です。だから、createUserメソッドは次のようになります。

public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status) 
{ 
    bool userExists = GetUser(email); 
    if (userExists) { 
     status = MembershipCreateStatus.DuplicateEmail; 
     return null; 
    } 
    bool? tryExists = regTryExists(email); 
    if (tryExists.HasValue && tryExists.Value && !userExists) 
    { 
     UserRepository.CreateUser(email, password); 
     status = MembershipCreateStatus.Success; 
     return GetUser(email); 
    } 

    return null; 
} 

また、このように私はFindUsersByName方法、GetUserNameByEmailを必要としません:

public override string GetUserNameByEmail(string email) 
{ 
    return email; 
} 

public override MembershipUserCollection FindUsersByName(string usernameToMatch, int pageIndex, int pageSize, out int totalRecords) 
{ 
    throw new NotImplementedException(); 
} 

だからここに私はusername, passwordQuestion, passwordAnswer, isApproved引数を必要としません。

また、私のシステムではユーザーからの質問はありませんので、私は

public override bool ChangePasswordQuestionAndAnswer(string username, string password, string newPasswordQuestion, string newPasswordAnswer) 
{ 
    return false; 
} 
public override string ResetPassword(string username, string answer) 
{ 
    throw new NotImplementedException(); 
} 

ような方法を必要としないそしてこれは、廃棄物と面倒な会員制のほんの一部です。それは私が望むほどリアルではありません。

質問がありますので、MembershipProviderに行く価値はありますか?私を連れてきてください。 MembershipSystemには本当に価値のあるシステムになる利点がありますか?

答えて

4

MembershipProviderを使用することは基本的にビルドや購入の決定になります。スクラッチ、または既製品を購入することができます(この場合は、既存のツールを使用してください)。

MembershipProviderは完璧ではありません。ちょっと不器用で、おそらく必要以上のものがあるかもしれませんが、そこの85%ですほとんどの実装ではそして、他の人に暗示されているように、自分の認証システムを最初から構築することは、時間や労力に値するものではありません。 これは解決された問題です;開発のエネルギーを使って、緊急かつ関連するビジネス上の問題を解決し、ホイールを再発明する必要はありません。

この公理を覚えておいてください:最初から何かを開発することで直接的な競争上の優位性を得ることができない場合は、既存のツールを使って(買って、ビルドしないで)良いです。

+0

しかし、私は厄介なツールを使うことにさらなる努力をしても、「開発のエネルギー」があればこの無駄ではないでしょうか? – kseen

+0

私のdev-mgr帽子を置いて、このビルド・バイ・シナリオのROIを決定しましょう。ビルド:独自の認証プロバイダ(dbデザイン、CRUD sprocs(25個あります!)、テストなど)をビルドする週数(少なくとも** **)。 「購入する」(つまり、既存のMembershipProviderを使用する):数日間悩まされ、いくつかのsprocs /メソッドを再トラッキングしてから、あなたの人生を乗り切らなければならない。 完全に新しいasp.net認証システムを構築し、それをGitHubに投稿してすべての栄光を得たいのでなければ、気にしないでください! –

+0

あなたの説明をありがとう!非常に良い考え。あなたが私の疑問をすべて破ったように見える! Btw CRUDの25のprocsは何ですか? – kseen

0

よくMembershipProviderが役に立ちます。完全なASP.Netセキュリティインフラストラクチャは、その周りに構築されています。コントロールの多くは、Login、LoginStatusなどのインフラストラクチャと直接対話できます。だからそれは有利だ。
しかし、それはまた、その太ったインタフェースのために問題のかなりの部分を持っています。界面分離の原理を破っているため、使用するのが少し面倒です。私はここで支払うペナルティよりも利点が大きいと信じています。だから、単純な回避策がある限り、それを使用しても害はありません。
独自のセキュリティインフラストラクチャを構築することも簡単な作業ではありません。 ASP.NETメンバシッププロバイダAPIの

1

いくつかの利点は:

  • あなたは車輪の再発明する必要はありません。プロジェクトの新しい参加者は、よく知られているAPIに精通しています。
  • 再利用や再利用が可能な実装(SQL Server、Active Directoryがほとんど)があります。
  • これは、視覚的にあなたはそれが実際にあなたのプロバイダをチェックするための良い方法です(ユーザーに&役割を作成するために、組み込みのASP.NET管理ツールを使用することができます
  • ASP.NET(ログイン制御、など)と統合されていますが正常に動作します
  • これは、.NET(ASP.NETだけでなく)のIdentity/Principalクラスと統合することができ、PermissionAttributeシステム(関連付けられたロールプロバイダを使用)をサポートするために使用できます。これは技術的にSystem.Web.dllに存在しますが、実際にはWeb以外のシステムでも使用できます。
  • 最後の一つですが、非常に興味深い:あなたはまた、デフォルトMembershipProviderは、あなたがそれを行うために必要なすべてを行うようですねWCF services
+0

既存の実装もあまり信頼性が高く、煩雑ではありません。そして非常にDBスキームに縛られています。したがって、dbスキームはまったく変更できません。 3番目の項目は、MVCアーキテクチャには適用されません。 – kseen

+0

私は「信頼できる」用語に同意しません。彼らはかなり信頼性があり、6年以上にわたって存在し、多くの人々によって使用されています。彼らは「面倒ですか」?私はもっ​​と意見の問題だと思う:-)あなたは本当に彼らが変更されるように設計されていないという事実には、あなたはそれらを使用するか、自分で書き直す必要があります。 –

0

にASP.NETメンバーシッププロバイダを使用することができます。
したがって、私は間違いなくMembershipProviderをラップするUserBusinessクラスを作成し、使用する機能のみを公開することをお勧めします。

これは、MembershipProviderの優れた機能を使いやすくするだけでなく、必要に応じてインターフェイスを簡素化します。

+0

コードサンプルで回答を編集していただけますか? – kseen

0

私はカスタムプロバイダを最初に使用しましたが、今は完全にスイッチアウトしました。

私は別のデータベースとマルチテナントサポートが必要になるまで、私はカスタムプロバイダと大丈夫だったパスワードをハッシュする方法をユーザーにロックするときのようなもの、など

ちょうど原則を保ちました。最後に、メンバーシッププロバイダを使用したユニットテストWCFサービスへの私の試みでした。今、私はMembershipServiceを持っていて、人生は良いです。私はまだオリジナルとほぼ同じデータ構造を持っていますが、.NETで私は自分のコードを使用します

関連する問題