php - 从请求填充实体的更好方法？

Question

我正在使用 Symfony 2.1 应用程序，我有很多参数通过 POST 发送。请求，我正在寻找一种更智能的方法来获取每个请求参数并填充我的实体类。我希望避免写 $entity->setMyParam($my_param) n 的表达式请求参数。例如，这是我的实体的片段:

namespace Brea\ApiBundle\Entity;

use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Validator\Constraints as Assert;

/**
 * Brea\ApiBundle\Entity\Distributions
 *
 * @ORM\Table(name="distributions")
 * @ORM\Entity
 */
class Distributions
{
  /**
   * @var string $recordType
   *
   * @ORM\Column(name="record_type", type="string", nullable=false)
   * @Assert\NotBlank()
   * @Assert\Choice(choices = {"a", "b", "c", "d", "e"}, message = "Choose a valid record type")
   */
  private $recordType;

  /**
   * Set recordType
   *
   * @param string $recordType
   */
  public function setRecordType($recordType)
  {
    $this->recordType = $recordType;
  }

  /**
   * Get recordType
   *
   * @return string 
   */
  public function getRecordType()
  {
    return $this->recordType;
  }
}

我的 Controller 尝试接受每个请求，将参数驼峰化并将请求参数的值设置为实体:

public function createRecordAction(Request $request, $id)
{
  $distribution = new Distributions();
  $params = $request->request;

  foreach ($request->request->all() as $param=>$value)
  {
    if ($param == "_method")
      continue;

    $function = "set".str_replace(' ','',ucwords(preg_replace('/[^A-Z^a-z^0-9]+/',' ',$param)));
    $distribution->$function($value);
  }
}

它有效，但我对这种方法的疑虑是我需要在每个执行类似操作的 Controller 中运行此代码。我可以将它重构为父类作为避免重复代码的方法，但我很好奇这是否是一个好的做法。我在 Symfony 框架中寻找已经做到这一点的东西，但我能找到的只是将请求绑定(bind)到表单的示例。

Answer 1

首先:警告!!

正如我之前评论的那样，我会非常小心地使用您原始帖子中提供的代码，因为您说它是来自 POST 的数据。请求，这意味着客户端可以在其中注入(inject)任何类型的数据并调用您可能不需要的函数(或者只是通过向您发送不存在的函数名称而导致脚本失败)。

我实际上会先阅读结论..! :) 然后回到Alt。 1 & 2。

备选方案 1:

话虽如此，您的问题的另一种解决方案是让对象负责获取自己的数据。有了足够细化的对象，您不应该以臃肿的代码结束，并且您可以在每个类中定义要查找的参数和要调用的函数(并在对类进行更改时进行本地化更改):

class BookInformation{
  private $publisher;
  private $name;
  private $price;

  public static createFromRequest($req){
    $publisher = Publisher::createFromRequest($req);
    $book = new BookInformation($publisher, $req['book_name'], $req['book_price']);
    $book->setABC($req['abc']);
    //...
    return $book;
  }

  public __construct($publisher, $name, $price){
    //...
  }
}

class Publisher{
  private $name;
  private $address;

  public static createFromRequest($req){
    return new Publisher($req['publisher_name'], $req['publisher_address']);
  }

  public __construct($name, $address){
    //...
  }
}

就像我之前说的，这种方法的一大优点是，如果您需要向这些类中的任何一个添加新属性，则根本不必编辑 Controller ，只需编辑“从请求方法初始化”即可。 future 的更改将本地化为修改后的类。

当然，不要忘记验证从用户请求发送的任何数据(但这只是常识)。

备选方案 2:

请注意，第一个选项与 Factory pattern 非常相似。 (基于 GoF 的抽象工厂)，并且您还可以使用该模式实现解决方案:

class BookFactory{
  public createBookInformation($req){
    $publisher = $this->createPublisher($req);
    $book = new BookInformation($publisher, $req['book_name'], $req['book_price']);
    $book->setABC($req['abc']);
    //...
    return $book;
  }

  public createPublisher($req){
    return new Publisher($req['publisher_name'], $req['publisher_address']);
  }

  //createAnythingRelatedToBooks($req)...
}

这样，您就拥有了 中的所有初始化过程。非常有凝聚力的类，它的唯一职责是根据请求对象初始化某个对象系列 (这是一件非常好的事情)。但是，如果向其中一个类添加属性，则还必须编辑相应的工厂方法。

结论

请注意，这两个替代方案实际上并不是真正的替代方案......它们可以与您的初始代码(尤其是工厂代码)一起使用。他们真的只解决了你的最后一个问题(“把代码放在哪里”的问题)。

但是，即使您确实对 POST 进行了 sanitizer request 并且只调用被注释的函数(如前所述)，我真的不建议这样做，因为我觉得更复杂的业务规则会很快破坏设计(但也许你已经把它全部覆盖了(？ ))。也就是说，我不认为您可以轻松地在初始化过程中插入业务规则，因为它是完全自动的(它不能对值进行任何验证，因为它可能是任何类型的值)而且我觉得您初始化后最终会“撤消”东西(我个人讨厌......很多错误空间)!

例如，在备选方案 1 中采用相同的两个类( BookInformation 和 Publisher )。

假设一个 Book只能有一个 Publisher如果那 Publisher已经在数据库中注册并且他们的地址已经被确认(需要使用另一个界面创建新的出版商，然后在他们可以链接到一本书之前确认他们的地址)。

否则，无论请求数据如何， publisher应设置为 XYZ。我有一种感觉(我可能是错的)要支持这些规则，您必须实际(自动)构建对象 然后 销毁/重新分配 publisher属性，如果它不符合某些规则。现在，如果你有一个池子 Publisher内存中的对象，还需要记得删除错误创建的 Publisher在那个池子里。这只是一个规则!

你可以用你的代码来“修复”这个问题的一件事是为每个 setter (validXYZ()) 设置一个验证方法，但是如果验证依赖于其他设置，它开始看起来像一个很快就会崩溃的设计对象/数据...

我真的没有其他任何东西可以阻止您使用该代码，但是如果您这样做了，请让我们在一两年后了解它的工作情况(一旦添加了一些维护/新功能等。 .)