首先,在我看來,我想建議你不要以爲基於它之上的面向對象的軟件解決方案關係的設計。
以最後一句爲真,我的暗示將每種類型的實體有什麼東西在企業做,你會設計一個數據表吧。
無論如何,我發現你可以有另一個關係設計。爲什麼不創建這樣的「用戶」表,其中包含基本信息,如唯一標識符,憑證以及用戶標識,身份驗證和授權所需的任何其他基本信息?
到這一點,你會設計的名爲「TrainerUsersProfiles」,「PlayerUsersProfiles」等關係表。
事實上,「TrainerUsersProfiles」,「PlayerUsersProfiles」有點像一個配置文件數據,因爲你是在爲了認證和授權應用程序的資源的用戶。但用戶可以擁有更多的相關信息,稱其爲「個人資料」。作爲培訓師或玩家的任何信息都是用戶個人資料的一部分。
現在是時候查看教練員和玩家(以及其他玩家)共享哪些屬性。這種共享屬性應該位於用戶的個人資料表「UsersProfiles」中,該表與用戶具有一對一的關係。
例如,我會在「TrainerUsersProfiles」和「PlayerUsersProfiles」中放置任何擴展配置文件數據,並且這兩個(或更多)將與某些用戶配置文件具有一對一的關係。
總結:用戶有一個配置文件,並且一個配置文件具有擴展的專用配置文件數據。
談到面向對象層 - 應用程序 - ,我想建議其最好避免抽象工廠和只使用一個存儲庫:
userRepository.GetById([id])
User類將有一個「類「屬性,這是一個用戶配置文件類型(培訓師,播放器等)的枚舉。
另外,User類還有一個「Profile」屬性,它本身也應該有一個「Properties」屬性。 「屬性」是一種類似於「ProfileProperties」的類型,並且有一個「TrainerProperties」和「PlayerProperties」派生它。
最後,這將是一些示例用法:
User someUser = userRepository.GetById([id]);
string somePropertyValue = null;
switch(someUser.Kind)
{
case Trainer:
somePropertyValue = ((TrainerProperties)someUser.Profile.Properties).SomeTrainerProperty;
break;
case Player:
somePropertyValue = ((PlayerProperties)someUser.Profile.Properties).SomePlayerProperty;
break;
}
我相信這可能是你正確的解決方案,它可以在一個良好的關係結束,面向對象的設計。
這聽起來很有趣,它也解決了我遇到的另一個問題,即用戶可能既是玩家又是教練。通過添加配置文件列表,我可以解決這個問題,甚至可以讓用戶成爲玩家/培訓師/推薦人或以往任何人...... – 2011-03-04 18:32:47
是的,這就是解決方案的要點。很高興知道它對您的解決方案有用! – 2011-03-05 14:04:50