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

不，这不是一个好主意。如果不出意外，将会违反Single responsibility principle。

如果您正在制作ORM，您的实例应仅处理数据存储/检索。在您的示例中，getDuration()是域业务逻辑的一部分，应位于domain objects内。

基本上，您在这里处理的是data mapper和active record模式之间的区别。而且，如果您正在尝试编写符合SOLID原则的代码，那么人们会认为活动记录是反对的，这在长期内会导致无法使用technical debt。

Answer 2

除非有某些特定于应用程序的原因没有该功能，否则答案很大。让我解释一下原因：

在OOP中，对象不仅仅是一个数据结构。它将国家和行为联系在一起。这是OOP的基本原则。它有一个状态，它有修改状态的方法。什么是实体？它是一个对象，一个业务对象。业务对象包含业务数据和逻辑。因此，他们确实需要具有执行业务逻辑的方法。从业务对象中删除业务逻辑违背了OOP的本质。因为，最终你需要在某个地方实现这种逻辑，但这不是正确的地方。该代码将以某种方式需要访问业务对象的状态，并且在大多数情况下会破坏信息隐藏（封装）的原则，这是我们首先拥有OOP的原因之一。
< / LI>
现在，关于ORM！在这里，您有两个需要实现，一个面向对象的设计和ORM。现在问哪一个优先于另一个，或者哪一个优先。您是先首先考虑ORM（或任何其他存储方式）然后设计您的课程吗？或者你设计你的类，然后映射/存储它们？第一种方法是正确的方法。您设计应用程序，然后让ORM遵循此设计。
非访问者方法是否会阻止您使用ORM。没有。这些方法不会阻止您在对象上使用ORM。 ORM框架的设计者在设计它时就知道了原理。

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

2 个答案: