我的应用程序中有一个复杂的定价机制 - 以下是我设置阶段的一些业务规则(实体是粗体):

• 一个产品可能具有独特的价位对于给定的客户,网站或客户群.
• 一个产品有时可以有一个或多个附加选项,可能有自己的价格点 或 价格规则.
• 甲产品具有一个独特的添加由用户,这本质上是一种价格和一个整数选择.

现在,我有一个价格点的EntityRepository,基本上确定了基本产品的正确价格点.这同样适用于在独特的加法和选项.

PricePointRepository

public function getThePrice($Product, $qty, $Website, $Customer = null) 
{
    //all logic to get product price for this given instance goes here. Good.
}

控制器(简化)

public function indexAction() 
{
    $Product = $em->dostuffwithpostdata;
    $qty = POST['qty']; //inb4insecure trolls
    $Website = $em->dostuff();
    $Customer = (if …

我知道这已被一遍又一遍地问过,我读了主题,但它总是专注于特定的情况,我通常试图理解为什么在实体中使用服务不是最好的做法.

给定一个非常简单的服务:

Class Age
{
  private $date1;
  private $date2;
  private $format;

  const ym = "%y years and %m month"
  const ...


  // some DateTime()->diff() methods, checking, formating the entry formats, returning different period formats for eg.
  }

和一个简单的实体:

Class People
{
  private $firstname;
  private $lastname;
  private $birthday;

  }

从控制器,我想做:

$som1 = new People('Paul', 'Smith', '1970-01-01');
$som1->getAge();

当然,我可以重写getAge()我的实体内部的功能,它不长,但我非常懒,因为我已经写了所有可能的datetime-> diff()我需要在上面的服务,我不明白为什么我不应该使用' EM ...

注意:我的问题不是关于如何在我的实体中注入容器,我可以理解为什么这没有意义,但更多的是避免在不同实​​体中重写相同功能的最佳实践.

继承似乎是一个糟糕的"好主意",因为我可以在类BlogArticle中使用getAge(),我怀疑这个BlogArticle类应该继承与People类相同的类...

希望我很清楚,但不确定......

我正在努力练习一个好的设计并扩展Doctrine实体.我的扩展类(基本上是模型)将具有额外的业务逻辑+访问实体基本数据.

我正在使用Doctrine 2.2.1和Zend Framework 1.11.4和php 5.3.8

当我使用DQL时,doctrine成功返回Model实体.当我使用Doctrine native find()函数时,它什么都不返回:(.

救命...

这是它如何滚动:

Bootstrap.php:

    $classLoader = new \Doctrine\Common\ClassLoader('Entities', APPLICATION_PATH.'/doctrine');
    $classLoader->register();
    $classLoader = new \Doctrine\Common\ClassLoader('Models', APPLICATION_PATH);
    $classLoader->register();

APPLICATION_PATH\models\User.php中的模型:

namespace Models;
use Doctrine\ORM\Query;

/**
 * Models\User
 *
 * @Table(name="user")
 * @Entity
 */
class User extends \Entities\User {

public function __wakeup() {
    $this->tools = new Application_App_Tools();
}

实体检索功能:

不工作:

$userEntity = $registry->entityManager->find('Models\User', $userEntity);

工作:

$qry = $qb
        ->select('u')
        ->from('Models\User','u'); 

正如我艰难地了解到，实体不应该存储任何真正的逻辑，因为它们的用途是存储数据。

另外，我读到控制器不应该有任何“真正的代码”，而只在需要时设置一些值并将它们指向实际用于工作的服务。（从控制器中修剪脂肪）。

我理解这些要点，即使我是 Symfony 的新手，我也知道带有“适用于所有事物”的代码的类是非常糟糕的做法（整个 Symfony Book 和 Symfony Cookbook 中的控制器确实看起来像那样）。易于创建，无法维护。而且，如果您遇到必须将代码解耦的情况，那么您会从中获得很多乐趣。但我明白了，因为这些书主要针对新人。

那么，我如何实际创建Entity Type Managers。他们是要走的路吗？

假设我有一个Image实体。我需要ImageManager来删除、更新、调用缩略图服务来创建缩略图等。它在哪里？它到底属于目录结构的什么地方？它不能是未映射的实体，因为它需要将服务注入其中。

最佳实践食谱文章没有提到类似的内容。