7

我正在使用 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;
  }
}

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

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);
  }
}

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

4

2 回答 2

1

我在 Symfony 框架中寻找已经这样做的东西，但我能找到的只是将请求绑定到表单的示例。

我会为此使用Forms 。即使 HTTP 请求不是从 HTMl 表单执行的，您也可以将其绑定Request到表单实例：它将负责所有数据注入和验证。

另外，如果您需要 HTML 表单，您可以准备好它们 ^^。

于 2012-12-28T17:05:14.007 回答
1

首先：警告！！

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

我实际上会先阅读结论..！:) 然后回到 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){
    //...
  }
}

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

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

备选方案 2：

请注意，第一个替代方案与工厂模式（基于 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请求并且只调用了注释的函数（如前所述），我也不会真的建议这样做，因为我觉得更复杂的业务规则会很快破坏设计（但也许你'已经涵盖了所有内容（？））。也就是说，我认为您不能轻松地在初始化过程中插入业务规则，因为它是完全自动的（它不能对值进行任何验证，因为它可以是任何类型的值）而且我觉得你会初始化后结束“撤消”的东西（我个人讨厌......很多错误的空间）！

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

假设 aBook只有在Publisher已经Publisher在数据库中注册并且他们的地址已经确认的情况下才能拥有 a（需要使用另一个接口创建新的出版商，然后在他们可以链接到一本书之前确认他们的地址）。

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

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

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

于 2012-12-28T16:12:15.957 回答