幫助我決定是使用ASP.NET默認成員資格/角色提供程序還是編寫自定義提供程序

Question

昨天我花了大量時間閱讀這個主題，但仍然覺得我不知道該走哪條路。 在身份驗證和授權方面，我來自“自己動手”的背景。 我們從未使用過Forms身份驗證，更不用說Membership API了。 看看我們的舊代碼，我們將使用會話變量來捕獲/控制用戶是否已登錄等。通過這個新項目，我即將承諾，我想讓我們回到正軌，我們應該開始做什么，哪個是使用框架提供的工具。

我已經有了一個我將要使用的數據庫模式，但它並不是一成不變的; 如有必要，我可以對其進行更改。 在此模式中，已有一個Users表，使用整數作為主鍵。 此表還包含其他信息，如名字和姓氏。 我還有基於UserId的外鍵到其他表，如電話和地址。 下面我概述一些想到的優點/缺點。

默認提供商

優點

• 更少的代碼。
• 能夠利用所有相關的服務器控件，例如Login，ChangePassword。

缺點

• 有些控件可能不會對我開箱即用。 例如CreateUserWizard，我將需要在用戶創建期間捕獲其他信息，例如電話和地址信息到關聯表。 不確定這是否會使這個控件對我無用。
• 我必須在我的關聯表（電話，地址）中創建外鍵到UserId，這是默認提供程序中的GUID。
• 如果我確實創建了這些外鍵約束而不使用級聯刪除; 我還需要刪除外鍵表中的關聯行。 可能必須使用類似TransactionScope對象的東西來確保所有這些都是原子操作。

定制提供商

優點

• 能夠利用現有的架構表。
• 更容易將身份驗證/授權提取到服務中。

缺點

• 必須自己為大多數/一切提供實施。
• 要使用任何控件，我必須在提供程序中提供所需的實現。

可能還有其他我還沒有考慮過的事情，因為我之前從未使用過這個，這讓我有點不舒服。

謝謝。

Answer 1

我最近不得不做出同樣的選擇，並決定創建一個自定義提供商。

我這樣做的最大原因歸結為默認的db模式。 所有默認的db對象都是在dbo架構中創建的，並以'aspnet_'或'vw_aspnet'等為前綴。對我而言，這是一次真正的岔路。 如果還沒有看到它們，請運行aspnet_regsql.exe來創建它們。

此外，Steven Sanderson在Pro ASP.NET MVC 2框架中說這個：

... SqlProfileProvider使用特別惡心的數據庫模式，其中配置文件條目存儲為冒號分隔的名稱/值對，因此基本上無法查詢。

總的來說，由於關注點明確分離，項目間重用以及與ASP.NET的其余部分集成，因此值得關注API，但是您只希望將內置SQL存儲提供程序用於小型或一次性項目。

我還沒有完成創建自定義提供程序的整個過程（我在使用Azure Table存儲時做了部分實現），但我計划將來在多個項目中使用這些提供程序，所以我覺得努力將是值得的。

Answer 2

如果您正在構建一個新的應用程序，我會毫不猶豫地使用asp.net默認提供程序。 您始終可以決定不使用默認控件並以編程方式創建自己的控件。 您還可以使用任何開源預先創建的用戶管理工具來節省大量時間。 同時，您始終可以將包含的信息擴展到默認表中。

Answer 3

就個人而言，我使用SqlMembershipProvider作為獨立實體，而我的數據庫的其余部分在Oracle中。 我從不看數據庫，因此名字和GUID不會打擾我（看不見，不在乎）。 它只是開箱即用，這太棒了！

在我的場景中，我在Oracle數據庫中有一個用戶表，我在創建/刪除成員資格用戶時沒有插入/刪除（沒有GUID）。 我認為成員資格數據庫是“主”記錄，而Oracle表基本上是支持表的參照完整性。 在官方交易中並沒有真正完成，但我使用try / catch來保持它們的同步性。

角色提供者是非常有限的，如果你想要任何類型的分層或動態角色，你就會被烘烤。 但它是一個完全獨立於會員資格的獨立系統，您不必使用它。

控制還不錯。 它們中的很多都支持模板，因此您可以向它們添加自己的控件，並有大量事件可以掛鈎。 不要害怕滾動自己的控件，但首先給出默認控件。 Membership API的易用性確實有助於創建這些控件。

Answer 4

就個人而言，我會選擇框架提供的內容。 在這種情況下，沒有理由推出自己的身份驗證。

在過去，你可能想要自己做事，但現在沒有理由這樣做。

我想如果你試圖自己寫這個，你就會重新創建輪子，這需要花費太多的時間和資源才能做到正確。 特別是在處理安全問題時。