2009-04-25 74 views
1

我有一個與配置文件相關的建模問題。首先,我研究了使用SQLTableProvider並使用內置的分析系統,但並不覺得它們合適。所以,據說,我有一個會員制度,每個人都有個人資料,那麼這個人可以將他們的個人資料升級到個人(附加領域)或公司帳戶(再次提供額外的領域)。擴展與另外兩層的成員配置文件 - asp.net mvc

所以我想,使用一個配置文件基類,然後繼承公司帳戶和個人帳戶。但是,當涉及到在MVC中實現這個功能時,我遇到了一堵磚牆。

由於公司或個人編輯頁面正在有效更新基本配置文件表以及同一頁面中的個人/公司表。我將如何去實現這個模型(目前通過LinqToSQL生成)以及視圖級別?

道歉,如果這不是很清楚,棘手的解釋!

回答

2

如果你使用Linq to SQL,那麼你已經有了一個模型。 Linq根據您的數據庫爲您生成實體和集合。生成的模型是淺層模型,但非常穩固可行。 Linq to SQL模型可以通過部分類進行擴展,使您可以增強實體或上下文本身以獲得更多功能。

控制器可以直接針對生成的模型工作,並根據需要將實體或實體集合傳遞給視圖。

我建議,對於您似乎正在嘗試做的事情,您可能會考慮不使用內置配置文件提供程序系統。 asp.net中的配置文件提供程序適用於簡單的個性化內容,但對於聯繫信息等具體數據並不適用。另外請記住,配置文件提供程序系統傾向於將對象數據作爲序列化字符串存儲在數據庫中......這使得從管理工具等獲取配置文件數據非常困難。在任何情況下,如果需要多個用戶的配置文件信息(例如使用管理員用戶編輯器),性能開始變得非常快。

對於當您存儲重要個人資料(如您提到的內容)時,您實際存儲的是「帳戶詳細信息」而不是「用戶配置文件」。您可以擴展成員資格提供程序以公開您的其他詳細信息,但我通常發現,只需推出自己的數據模型和訪問邏輯以處理額外的帳戶信息就容易多了。

我的經驗法則是這樣的:如果在用戶對數據所屬的請求期間只需要該信息,那麼它就進入配置文件。如果我需要一個用戶的數據在另一個用戶的請求期間被讀取,或者如果我需要不同用戶的數據「列表」,那麼它不會在asp.net配置文件中。

+0

感謝Stephen的投入。我確實反對使用內置配置文件,因爲您提到的原因非常好,以至於我知道我在那裏的正確軌道上。 更多地思考它,我認爲我的主要問題是圍繞從一個視圖/控制器動作更新兩個表/模型,但我很肯定我現在已經有了前進的方向。 – Steve 2009-04-26 07:25:08

0

你是指像選擇在每個頁面上查看多少項目以及選擇一些樣式表之類的設置?

public class Profile 
{ 
    int? ItemsPerPage { get; set; } 
    string PreferredStyleSheet { get; set; } 
} 

該公司選擇一些值將爲用戶工作,除非用戶爲他們自己選擇了其他值。這是你的想法嗎?


在這種情況下,我不知道該怎麼做起來的ASP.NET配置文件,但如何在數據庫中的以下表:

TABLE Setting 
(
    SettingID int NOT NULL, 
    SettingName varchar(32) NOT NULL, 
    DefaultValue nvarchar(128) NULL 
) 
TABLE CompanySetting 
(
    CompanySettingID int NOT NULL, 
    RefSettingID int NOT NULL, 
    RefCompanyID int NOT NULL, 
    SettingValue nvarchar(128) NOT NULL 
) 
TABLE UserSetting 
(
    UserSettingID int NOT NULL, 
    RefSettingID int NOT NULL, 
    RefUserId uniqueidentifier NOT NULL, 
    SettingValue nvarchar(128) NOT NULL 
) 

然後做一些加入了當前用戶。如果沒有給出用戶設置,請進行公司設置;如果未提供公司設置,則採用默認值。

+0

謝謝奧萊,但不是真的我以後。每種不同類型的個人資料的詳細信息都是地址細節,工作經驗等類型的東西。 我已經把數據庫建模得很好,它承載了MVC,我遇到了麻煩。如何在模型層上表示表結構並在視圖中顯示它們。 更有意義嗎? – Steve 2009-04-25 16:02:20