SqlMembershipProvider vs自定義解決方案

Question

我在一個小團隊的開發人員的工作，並沒有達成一致的核心任務，其中一個是成員資格提供商的最佳方法的共識。現在我不能確定這是否涉及到缺乏替代思維方式或足夠規模的項目以保證進行重大調查。

我一直是一個.NET網絡開發人員多年（以及之前的PHP和ASP經典），並且通常在開發應用程序時，我害怕使用內置的.net SqlMembershipProvider，這主要是因爲它經常顯得過分其次，因爲我只能想象這樣一個複雜的數據模型可能會有性能問題。

通常我使用一個自定義成員資格和角色提供程序在相當簡單的user -> user roles <- roles類型模式上運行。根據相關應用程序的需求，我維護標準的成員資格提供程序功能，例如帳戶恢復，配置文件詳細信息，失敗的登錄帳戶鎖定，祕密問題等，例如AD安全應用程序具有少量附加功能，面向公衆的應用程序通常具有商場。這也意味着任何需要存儲過程的任務都需要咀嚼用戶數據，這些任務很容易編寫和執行。直接的SQL命令，良好的索引和簡單的數據模型導致高性能，可伸縮的解決方案，這應該需要改變我完全可以控制需要改變，我認爲這是非常寶貴的。

根據你的經驗，你會說這是一個過時的方法？內置提供程序是否存在可擴展性問題？你通常採取什麼方法以及在什麼情況下？

感謝

Answer 1

除非你明確地確定了不合理的理由，否則我建議你從SQLMembershipProvider開始，並根據需要對其進行調整。

我們發現內置提供程序給了我們所有的基本知識，而我們幾乎沒有任何工作。要建立一個良好的安全結構有很多元素，很容易忘記其中的一個，或者只是爲了讓自己變得懶惰而不實現一個「正確」的方式。讓我們想起通過電子郵件重置密碼和密碼的事情。

當然，SQLMembershipProvider並不是什麼靈丹妙藥。我們遇到了一些情況，需要採取更復雜的身份驗證措施。但是我們能夠通過擴展SQLMembershipProvider來解決這些問題，而不是取而代之。有關更多詳情，請參閱我的回答What is a good way to extend .Net Membership to track user logins。

我們沒有注意到來自SQLMembershipProvider的任何重大性能問題，所以我認爲玩性能卡是沒有根據的。畢竟，用戶通常花費多少時間登錄系統？如果你所有的網頁加載速度都很快，那麼根據你可能會錯誤地改進性能的想法來編寫你自己的代碼是沒有道理的。這是我們一直在閱讀的可怕的「過早優化」。

Roles框架對我們的需求來說太簡單了，所以我們根本不使用它。但它也沒有成功。如Hogan指出的那樣，您更有可能找到已經熟悉內置提供者工作方式的開發人員，這意味着他們將花更少的時間來設法確定您的架構和（希望）有更多時間完成實際工作。

Answer 2

使用內置提供商應該更容易維護，並找到熟悉的API（招聘程序員的時候）資源。