2012-02-24 49 views
2

我期待創造在ASP.Net MVC3自定義成員資格提供者和很努力,看到這一切是如何結合在一起......如果我的用戶模型繼承的MembershipUser

我真的找一些最佳實踐如何做到這一點的方法。

我有一個用戶模型(represnting一個用戶表在我的數據庫)。爲了將這與MembershipProvider功能一起使用,此模型是否應該繼承MembershipUser? MembershipUser中有許多字段,我不在乎 - 這些必須在底層SQL表中才能使用這種方法(顯然這似乎是多餘的,因爲我永遠不會使用這些列?)

例如 - 我應該讓我的模型像這樣繼承MembershipUser嗎?

/// <summary> 
/// Class representing a registered user based on the Users database table. 
/// </summary> 
public class User : MembershipUser 
{ 
    public int Id { get; set; } 
    //here I can access some other properties I will use which are already in MembershipUser... 

    //Addtional properties I need specific to my app. 
    public bool NotifyOfNewBlog { get; set; } 
    public bool NotifyOfNewWallPosts { get; set; } 
    //...plus many more. 
} 

當談到進一步使用Membership.GetUser()向下行,我再抹上該對象每次回到我原來的User對象能夠訪問的附加屬性?

這是我應該採取的方法嗎?或者,我是單獨的User模型,然後是CustomMembershipUser模型,它鏈接回數據庫模型?

如果EF沒有將所有MembershipUser列作爲表中的對象,EF是否能夠保存/更新/插入用戶模型?這甚至在接近正確方法的地方嗎?正如你所看到的,我在這裏撓了撓頭。

任何意見/想法/想法,非常感謝。

+0

從純粹的設計角度來看,成員用戶更有可能擴展用戶,而不是反之亦然 – DVG 2012-02-24 12:17:34

+1

MembershipUser是一個.Net類,儘管 - 與MembershipProvider一起使用...因此需要我的User對象繼承它。 – 2012-02-24 12:20:33

回答

1

至於繼承MembershipUser對象的話,你可以做到這一點,並在實施的MembershipProvider的,只投了你的派生類型,但我個人不這樣做,只是因爲你是那麼的對這種類型的未來變化的憐憫打破你的派生類型(儘管這可以說我猜大部分框架)。我會把這些額外的值放到配置文件中,然後推出你自己的ProfileProvider,(不要使用Sql,這是我的經驗中的垃圾)。

「MembershipUser中有很多字段,我不在乎 - 這些必須在底層SQL表中才能使用此方法(顯然這似乎是多餘的,因爲我永遠不會使用列? )「

如果你正在滾動你自己,你可以不保存在Db中。畢竟,你正在實現MembershipProvider方法(GetUser等等),所以你對傳遞給你的MembershipUser對象做了什麼,取決於你。你可以忽略這些,而不是驗證或存儲它們。

1

我前段時間的問題很相似,最後我決定不用會員邏輯污染我的EF模型。我的應用程序中有我的數據訪問層,當他必須保存/更新數據時,我的EFMembershipProvider會使用它。如果我必須GET我的應用程序中的用戶數據(除了會員本身之外),我不使用會員(我不需要任何東西)。

我想弄清楚,如果你實現自己的成員資格提供

public class EFMembershipProvider : MembershipProvider 

可以抽象成員設施的基本功能,使用自己的模型/庫。

您可以在MVC3樣板

https://github.com/crdeutsch/MVC3-Boilerplate

在網絡/基礎設施找到一個實現成員提供了EF的例子(儘管你可能要修改它的大部分)。