我应该访问模型中的POST参数还是作为控制器的方法参数传递？

我必须处理大约20个POST参数，我不知道该在哪里做。我应该访问模型中的POST参数还是作为控制器的方法参数传递？

我可以将每个定义为模型上方法的参数，并在调用该方法时从控制器传递它们。这会导致相当多的工作，并且由于参数的数量而使函数调用的可读性降低。

或者我可以调用模型上的方法，并直接访问参数。

将参数作为参数传递会让我更好地控制函数访问哪些参数，并且文档更易于理解。但是如果稍后添加新参数，则必须将它们添加到方法调用的末尾，因为不会打破每个现有的调用。我想如果发生几次，这会变得相当混乱，因为参数不能在逻辑上分组。

如果我访问参数模型，没有参数必须从控制器到模型传递，使得调用该方法更简洁。但是我无法控制所访问的参数，因为它们可以很容易地，不受限制地添加或删除。这需要来自其他开发人员的更严格的纪律，而且我不喜欢依赖于此，因为迟早有人会“快速地（添加|更改|修复）”。

我不确定要走哪条路。我倾向于在模型中完成所有工作，因为写起来更快，似乎更容易维护（没有争论的混乱），从概念上讲更适合我对模型的看法。另一方面，我不确定我对模型的看法是否正确，如果我依赖于其他开发人员在每次更改后始终更新文档，那么它会混乱结束。

那么，我该怎么办？

来源

2009-08-18 Thomas

我选择不接受我的问题的任何答案，因为没有明确的答案。一般来说，我会遵循Ignas和Lucas的方法，因为数据受到更好的约束。对于我们的应用中的这种情况，karims答案更合适。 – Thomas 2009-08-18 14:27:12

嘛，为什么你就不能接受（关联）阵列作为模型中的该方法的参数，然后通过它的整个$ _POST阵列？至少在我看来，它不会破坏封装。

编辑：如果你不喜欢使用关联数组对于这一点，你也可以（在C它们仅用于承载数据对象，如结构），使用所谓的“纯老物件”。例如，如果这涉及到保存提交报名表：

class UserData 
{ 
    protected $name; 
    protected $username; 
    protected $password; 

    public function getName() { /* <...> */ } 
    public function setName() { /* <...> */ } 
    /* other accessors go here */ 
} 

class UserController extends Controller 
{ 
    public function register() 
    { 
     $userData = UserData::create() 
      ->setName($_POST['name']) 
      ->setUsername($_POST['username']) 
      ->setPassword($_POST['password']); 
     Users::add($userData); 
    } 
}

这将允许您使用严格类型的用户::增加，也使文档的过程更容易。

来源

2009-08-18 12:15:44

作者回复了我的回答：“这个问题确实类似，但我不喜欢传递关联数组”<...>“ – 2009-08-18 13:16:13

正如我对daff的回答，我绝对赞成将对象传递给关联数组，我会牢记你的榜样。 – Thomas 2009-08-18 13:44:09

前一阵子我回答了a similar question。 Imho你应该通过他们正如已经提出的关联数组（并且之前进行所有安全检查）。这样你就可以轻松地重用你的分类。

来源

2009-08-18 12:19:05 Daff

问题确实相似，但我不喜欢传递关联数组。对于文档和限制目的来说，它们基本上是无用的，因为我不能（或者仅仅通过巨大的努力）文档或限制其内容。他们成为我想扔进去的任何东西的船只。在这种情况下，验证在控制器中完成，如果失败，模型上的方法将不会被调用。所以传递一个关联数组并不能直接访问$ _POST。 – Thomas 2009-08-18 12:31:08

嗯，但它是PHP的基本语言结构，所以为什么不使用它。另一方面，如果你有一个合适的OO设计，你就不必在一次函数调用中处理20个参数。 – Daff 2009-08-18 13:10:55

我在数组中看到的问题是他们的“松散”，每个开发人员都可以添加或删除字段，并且没有人会注意到。类更好，因为它们定义了数据的结构。但在这种情况下，我会遵循karim79，因为我们不会更改POST阵列中的值。 – Thomas 2009-08-18 13:41:22

控制器。因为请求数据和模型操作不是一回事。因此，所有其他可能的请求都需要请求基于数据的逻辑模型，这就是不好的

来源

2009-08-18 13:29:08

我不认为访问参数算作逻辑。验证等已经完成控制器。此外，这种方法只适用于这种情况，因此没有计划将其用于其他请求。 – Thomas 2009-08-18 13:54:12

我一直在努力解决这个问题，而且我提出的解决方案非常灵活，可以保持我的代码的可重用性，并且是容忍前端的变化：我喜欢使用setters。当然，其每单价值二传手是一种痛苦，所以在逻辑方式分组的数据可以帮助：

 
$user = new User(); 
$user->setName($_POST['lastName'],$_POST['firstName']); 
$user->setAddress($_POST['address1'],$_POST['address2'],$_POST['city'],$_POST['state'],$_POST['zip']);

你明白了吧。一旦保存到对象变量中，就可以在所有对象的方法中使用这些值。

使您的模型依赖于超全球植物是如此僵化。这也让单元测试变得很痛苦。

来源

2009-08-18 13:38:45

这是一个有趣的建议。可悲的是，在这种情况下，我无法对任何参数进行上下文分组，因此我必须为每个参数设置一个setter，因此karim79解决方案使事情变得更加简单。但我会在其他情况下记住这一点。 – Thomas 2009-08-18 13:51:42

这是我做的......

//Object Oriented POST Replacement 
    if ($_SERVER['REQUEST_METHOD'] == 'POST') 
    { 
     $_POST = json_decode(file_get_contents('php://input')); 
    }

我主要写这与Content-Type: application/json传递信息了JSON的API。然而，无论如何填充$_POST，这都会起作用（并且在我看来更好）。

无论你在做什么，我建议把超级全局变成一个对象。在你的模型中，接受一个单一的对象作为参数，并取消属性或子属性。

从那里开始，只需设置控制器方法，就可以使用面向对象的超全局方法调用模型方法作为唯一参数。

来源

2017-01-03 21:57:41 Allenph

我应该访问模型中的POST参数还是作为控制器的方法参数传递？

回答

相关问题