要繼承還是不繼承？一些專業意見想要

我正在設計一個C＃ASP.Net Web應用程序，它使用了大量的通用功能和正確的方式來處理，似乎是通過繼承。我打算創建一個基類（Person），並在Employee和Vendor等其他類中繼承它，然後依次繼承Employee和Manager等。這樣，我不必定義常用屬性，如FirstName，LastName， PhoneNumber等等。要繼承還是不繼承？一些專業意見想要

問題的第二部分是這樣的：如果我使用繼承並使用實體框架的CodeFirst實體，他們會理解繼承嗎？數據將如何存儲在表中？每張表都有一個FirstName和LastName列，或者是EF足夠聰明以使它們成爲一個公用表？

我真的希望有人是一個真正的面向對象的程序員，可以幫助我清楚這一點。我收到了大量的信息，我需要有EF項目實際經驗的人給我一些指導。我理解繼承權嗎？如果沒有，我會發生什麼錯誤？任何幫助表示讚賞。

感謝，

伯特

來源

2013-07-23 user2611954

對於數據庫選擇，您提到的兩種選擇都是有效的，但有些更喜歡在許多表中重複公用數據，其他將創建一個表來存放與其相關的公用數據和其他表。 –

這不是一個簡單的問題，但對於大多數情況下，最好的選擇，而不是組成的繼承。您不應該僅僅因爲計算器具有顯示和鍵盤屬性而從計算器派生自動提款機。這很荒謬。
但有時繼承是有道理的。問問自己，這些班級應該是'一種'關係嗎？當我看到你的任務時，最好讓Vendor和Employee成爲獨立的類，都有Person屬性。從僱員派生經理。
儘管如此，仍然保持繼承的深度。深層次結構是調試和理解的痛處，特別是如果有很多方法覆蓋。欲瞭解更多關於該主題的靈感，請看Chad Myers blogpost。

來源

2013-07-23 19:53:50

首先1：聽起來不錯。但要確保給出一個「是」的關係。不要從Address來派生Person來包含地址特定的屬性 - 使用EF複合類型進行這種重用。

我想到的一個問題：你確定Vendor是Person的子類型嗎？

更多內容：確保您保留在您的繼承範圍內的「一個域」。正如Vinny在另一個可能的答案中發佈的，如果同一個人可能是Manager和CustomerContact並且都從Person繼承，那麼您遇到了問題。但是，如果管理人員和客戶聯繫人不在同一個域中，最好兩次添加人員數據 - 也許同一個人希望爲您提供與聯繫人不同的聯繫人數據。

第2部分：你可以選擇EF產生： http://www.entityframeworktutorial.net/code-first/inheritance-strategy-in-code-first.aspx

來源

2013-07-23 19:39:13

好點。這不是一個很好的例子。也許是「CustomerContact」之類的東西。這個例子剛剛彌補了這個問題，並沒有反映我將要創建的實際實體。 – user2611954

我還不確定你有什麼樣的衝突信息，但我可以添加關於你的問題的第一部分的更多具體信息。 –

從面向對象的角度來看，這種方法的問題是當一個人成爲經理，員工，供應商或所有人時。在一些拉丁語言中，我們必須爲動詞形成（ser/estar）。前者指的是存在的本質，後來涉及到國家。當引用存在的本質而不是其狀態時，最好使用isA作爲繼承。在你的情況下，我會建議使用角色。一個人有很多角色。經理是角色（經理繼承角色），員工是角色等。這樣，您可以重複使用您的人員屬性，並且您可以添加和刪除某人的角色。

來源

2013-07-23 19:56:29

要繼承還是不繼承？一些專業意見想要

回答

相關問題