使用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框架的设计者在设计原理时就知道这一原理。