單表繼承以及在Rails中使用它的位置我陷入了一個奇怪的設計問題，我正在研究兩種類型的模型，用戶個人資料（屬于用戶）其他在現場維護為“機器人”的人（不屬于任何人）這兩種類型的配置文件的典型OO行為是相同的，但只有重要的屬性/屬性是常見的（非常重要的屬性5-6），其他屬性如“興趣等”（幾乎10-15屬性）不存在用于bot配置文件之前參與此工作的編碼人員為機器人配置文件/用戶配置文件創建了單獨的模型/控制器，這在任何地方創建了大量冗余，并且預期難以維護，編寫測試等。我想干這個，至少解決一些/所有問題這些冗余問題。有人建議使用單表繼承作為解決方案有人建議使用多態關聯。什么是更好的方法。我們什么時候實際使用STI？我自己的想法是，當模型的屬性相同時，STI被最佳使用，并且它們的行為不同。關于我該怎么辦的想法？
3 回答
動漫人物
TA貢獻1815條經驗 獲得超10個贊
Rails中的單表繼承
簡而言之：對象之間需要有明確的OO風格的繼承關系（由womble雄辯地說明），而不僅僅是一些共享數據。如果沒有自然而明顯的類層次結構，隨著應用程序的發展，STI設計可能會變得難以維護。
其次，您應該考慮將所有數據放在一個表中是否很重要。使用多態關聯，您的數據庫查詢將變得更加復雜，并且可能更慢。如果您計劃在網站上列出所有對象（例如，在表格中），那么STI可能就是您的選擇。
第三，確保您的子類沒有太多的唯一屬性。使用一個表中的所有數據，您不需要很多非全局列。這些不僅會占用空間（不是主要問題），而且會使數據結構混亂。如果您有“特殊”列，則應在代碼中明確解釋它們。
最后，如果您使用STI，我強烈建議您為所有子模型使用單個控制器?？刂破鞯闹饕δ苁翘峁ο蟮脑L問，如果需要以非常不同的方式訪問對象，那么STI可能不是開始時的正確設計選擇。
慕俠2389804
TA貢獻1719條經驗 獲得超6個贊
我可能會使用STI或根本沒有特殊功能。您可以將所有內容稱為“個人檔案”，如果用戶為零則您知道它是否為“機器人”。您也可以在不使用STI的情況下存儲“類型”字段。
某些事情會影響我使用STI的決定：
是否存在特定于機器人的邏輯
有多少機器人與用戶配置文件（少數機器人意味著STI是好的 - 很多機器人，我可能會將它們存儲在其他地方）
避免STI的原因有時會妨礙你。例如，將對象從一種類型更改為另一種類型（在這種情況下為Bot到配置文件）可能相當煩人。有時一個簡單的“類型”字段更好。
值得注意的是，如果使用STI，您可能需要一個公共基類。所以，你可能希望Profile，BotProfile和UserProfile。這些名字取決于你。:)
- 3 回答
- 0 關注
- 549 瀏覽
添加回答
舉報
0/150
提交
取消