1

例如（不是逐字）

/**
@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 应该只是表，仅此而已？

这可能是一种主观观点，因为每个人都有自己的观点，但在编程中，你会做和你真的不应该做的事情。我只是想知道这是否是其中一种情况。

4

2 回答 2

1

不，这不是一个好主意。如果不出意外，将违反单一责任原则。

如果您正在制作 ORM，您的实例应该只处理数据存储/检索。在您的示例getDuration()中是域业务逻辑的一部分，应该驻留在域对象中。

基本上，您在这里处理的是数据映射器和活动记录模式之间的区别。而且，如果您尝试编写符合 SOLID 原则的代码，人们会认为活动记录是一种反模式，从长远来看，这会导致彻底的技术债务。

于 2012-07-04T23:50:49.283 回答
0

除非有一些特定于应用程序的原因不具备该功能，否则答案是肯定的。让我解释一下原因：

  1. 在 OOP 中，对象不仅仅是一种数据结构。它将状态和行为联系在一起。这是 OOP 的基本原则。它有一个状态，它有修改状态的方法。什么是实体？它是一个对象，一个业务对象。业务对象包含业务数据和逻辑。因此，他们确实需要具有执行业务逻辑的方法。从业务对象中删除业务逻辑是违背 OOP 的本质的。因为，最终您将需要在某个地方实现该逻辑，但这不是正确的地方。该代码将需要以某种方式访问​​业务对象的状态，这在大多数情况下会破坏信息隐藏（封装）的原则，这也是我们首先拥有 OOP 的原因之一。

  2. 现在，关于 ORM！在这里，您需要满足两个需求，面向对象设计和 ORM。现在询问哪个优先于另一个，或者，哪个优先。您是否首先考虑 ORM（或任何其他存储方式）然后设计您的类？或者你设计你的类，然后将它们映射/存储？第一种方法是正确的方法。你设计你的应用程序，然后让 ORM 遵循这个设计。

  3. 非访问器方法会阻止您使用 ORM。不。这些方法不会阻止您在对象上使用 ORM。ORM框架的设计者在设计的时候就知道这个原理。

于 2012-07-05T16:48:09.400 回答