使用ORM表示表時，具有非表特定的功能是否明智？

Question

例如（非逐字）

/**
@Entity
*/
class Event
{
   /**
      @Column 
   */
   protected $time_start;
   /** .. */
   protected $time_end;

   /** getters, setters, etc */

   /** @return duration of event as a string, non-table function */
   public function getDuration() { ... }
}

還是應該ORM只是表格，僅此而已？

這可能是一個主觀的觀點，因為每個人都有自己的觀點，但是在那里進行編程以及您要做的事情和您實際上不應做的事情。 我只是想知道這是否是其中一種情況。

Answer 1

不，這不是一個好主意。 如果沒有別的，那就違反了單一責任原則 。

如果要進行ORM，則實例應僅處理數據存儲/檢索。 在您的示例中， getDuration()是域業務邏輯的一部分，應駐留在域對象中 。

基本上，這里要處理的是數據映射器和活動記錄模式之間的區別。 而且，如果您嘗試編寫遵循SOLID原則的代碼，則人們會認為活動記錄是一種反模式，從長遠來看，這會導致不容置疑的技術債務 。

Answer 2

除非有某些特定於應用程序的原因不具有該功能，否則答案是肯定的。 讓我解釋一下原因：

1. 在OOP中，對象不僅是數據結構。 它將狀態和行為聯系在一起。 這是OOP的基本原理。 它具有狀態，並且具有修改狀態的方法。 什么是實體？ 它是一個對象，一個業務對象。 業務對象包含業務數據和邏輯。 因此，他們確實需要具有執行業務邏輯的方法。 從業務對象中刪除業務邏輯違反了OOP的本質。 因為，最終您將需要在某個地方實現該邏輯，但這並不是正確的選擇。 該代碼將以某種方式需要訪問業務對象的狀態，並且在大多數情況下，這將破壞信息隱藏（封裝）的原理，這是我們首先擁有OOP的原因之一。

2. 現在，關於ORM！ 在這里，您需要滿足兩個需求，即面向對象的設計和ORM。 現在，問哪個優先於另一個，或者哪個優先。 您是否首先考慮ORM（或任何其他存儲方式），然后再設計您的類？ 還是您設計類，然后將其映射/存儲？ 第一種方法是正確的方法。 您設計應用程序，然后讓ORM遵循此設計。

3. 非訪問者方法會阻止您使用ORM。 沒有。 這些方法不會阻止您在對象上使用ORM。 ORM框架的設計者在設計原理時就知道這一原理。