2014-01-23 25 views
8

我正在構建一個新的MVC應用程序。通常,我總是有一個項目結構,看起來像這樣:從UI層抽象asp.net mvc標識

  • DAL層(實體庫
  • 服務層(該API /前端和DAL)
  • 前端之間的協調面向業務的服務電話,這可以是網絡API或MVC應用程序

我的問題是,我總是以凌亂的用戶管理實現結束,我使用了成員資格提供程序,因此使該部分不如它應該好。看到了新的身份實施和我真實我喜歡它。我做了一些關於hot的搜索以將其抽象到後端,但沒有結果。

我發現這個職位如何組織該項目,但它沒有給出真正的答案:Decoupling ASP.NET MVC 5 Identity to allow implementing a layered application

我希望有人能爲我提供一些提示或技術文件如何抽象的所有登錄和驗證到後端層。

回答

4

您可以在業務層中創建一個非常基本的界面。這將是這個樣子:

public interface IAuthenticationService 
{ 
    bool VerifyPassword(User user, string password); 

    bool SignIn(User user); 

    void SignOut(); 
} 

您可以實現無論是在業務層,UI層或一個單獨的基礎設施層使用ASP.NET身份這個接口。

該接口可以通過不同的技術實現,這些技術可以在運行時通過IoC容器註冊,例如,您可以使用接口AccountController。由於認證框架往往會變化(每年左右),這使您可以更輕鬆地進行切換。

+0

但是,我怎樣才能使用我的控制器中的屬性以及如何實現oauth? – Patrick

+2

@Patrick如果您的意思是['Authorize'](http://msdn.microsoft.com/zh-cn/library/system.web.mvc.authorizeattribute(v = vs.118).aspx)屬性,您可以只要使用它,ASP.NET身份就會考慮到它。它位於'System.Web.Mvc'命名空間中,因此它對認證實現沒有直接的依賴關係。關於OAuth,我沒有經驗,所以我不確定是否可以將它抽象出來。 –

+1

只是好奇有人真的把它拉掉了嗎?這聽起來很簡單,但由於EF Identity實現包含在賬戶控制器中的擴展方法,我所下的路線可能會造成如此混亂。我從字面上試圖達到我可以完全從我的MVC項目中提取EF,Identity和EF Identity依賴項的程度。只是想看看有沒有人有過這方面/最佳實踐的例子,因爲我可能不得不重新開始。 – Shawn

4

從技術上講,它已經被抽象化了。 UserManager類是ASP.NET Identity的核心,它是數據庫上下文的包裝。現在,如果您正在討論進一步抽象,所以在您的代碼中根本沒有提及ASP.NET Identity,我認爲這是不必要的,但仍然有可能。您只需將所有代碼移動到您的服務層,然後撥打您的服務即可打到UserManager上的適當方法。儘管如此,你仍然需要傳遞你的上下文,所以你最終不會創建它的多個實例,肯定會對你產生影響。

+3

我不想擺脫我的代碼中的asp.net身份。只有在mvc項目中擺脫它,並將其放入服務層項目中。也許我應該開始將控制器中的所有代碼移動到服務器上,然後看看接下來應該做什麼。 – Patrick

+0

@Patrick如果將UserManager放入服務層,則必須從數據層傳遞dbContext(或IdbContext),這是錯誤的。你有解決方案嗎? – Arvand