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

发布于 2024-08-02 14:32:40 字数 561 浏览 11 评论 0原文

我必须处理大约 20 个 POST 参数,但我不知道在哪里处理。

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

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

将参数作为实参传递将使我能够更好地控制函数访问哪些参数,并且文档也更加不言自明。但是,如果稍后添加新参数,则必须将它们添加到方法调用的末尾,以免破坏每个现有的调用。我想,如果这种情况发生几次,就会变得非常混乱,因为无法对参数进行逻辑分组。

如果我访问模型中的参数,则无需将任何参数从控制器传递到模型,从而使方法调用更简洁。但我无法控制所访问的参数,因为它们可以轻松且不受限制地添加或删除。这将需要其他开发人员更加严格的纪律,我不喜欢依赖这一点,因为迟早有人会“只是(添加|更改|修复)这么快”。

我不知道该走哪条路。我倾向于在模型中完成所有操作,因为这样编写起来更快,似乎更容易维护(没有争论混乱)并且在概念上更适合我对模型的看法。 另一方面,我不确定我对模型的看法是否正确,如果我依赖其他开发人员在每次更改后始终更新文档,模型是否会陷入混乱。

那么,我该怎么办?

I have to process about 20 POST-parameters, and I am not sure where to do that.

I could define each as an argument of the method on the model, and pass them from the controller when the method is called. This would result in quite a bit of work and make the function call less readable, due to the number of arguments.

Or I could call the method on the model, and just directly access the parameters.

Passing the parameters as arguments would give me more control over which parameters the function accesses, and the documentation would more self-explanatory. But if new parameters were added later on, they would have to be added to the end of the method call, as not to break every existing call. I imagine that this would become quite confusing if it happens a few times, as the arguments can't be logically grouped.

If I access the parameter in the model, no parameters have to be passed from the controller to the model, making the method call terser. But I have no control over the parameters that are accessed, as they can easily and without restrictions be added or removed. This would require greater discipline from the other developers, and I dislike to depend on that, because sooner or later someone is bound to "just (add|change|fix) this real quick".

I'm not sure which way to go. I tend to just do it all in the model, as this is faster to write, seems easier to maintain (no argument chaos) and conceptually fits better into my view of a model.
On the other hand, I'm not sure my view of a model is correct, and if it will end in chaos if I depend on the other developers to always update the documentation after each change.

So, what should I do?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

抱着落日 2024-08-09 14:32:40

那么,为什么不能在模型的该方法中接受一个(关联)数组作为参数,然后将整个 $_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);
    }
}

这将允许您在 Users::add 中使用严格的类型,并使文档处理过程更容易。

Well, why can't you just accept an (associative) array as a parameter in that method of the model, and then pass it the whole $_POST array? At least in my opinion, it wouldn't break encapsulation.

EDIT: And if you don't like using associative arrays for that, you can also use so-called "Plain Old Objects" (objects which are only used to carry data, like structs in C). For example, if this involved saving a submitted registration form:

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

This would allow you to use strict typing in Users::add and also make the process of documentation easier.

禾厶谷欠 2024-08-09 14:32:40

我一直在努力解决同样的问题,我想出的解决方案很灵活,使我的代码可重用,并且能够容忍前端的更改:我喜欢使用设置器。当然,为每个值设置一个设置器是一件痛苦的事情,因此以逻辑方式对数据进行分组会有所帮助:

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

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

让你的模型依赖于超全局变量是非常不灵活的。这也让单元测试变得很痛苦。

I've struggled with this same issue, and the solution I came up with is flexible, keeps my code reusable, and is tolerant of changes to the front-end: I like using setters. Of course, having a setter for every single value is a pain, so grouping data in logical ways helps:

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

You get the point. Once saved to object variables, you can then use these values in all of your object's methods.

Making your models reliant on superglobals is so inflexible. It also makes unit testing a pain.

江湖彼岸 2024-08-09 14:32:40

我回答了类似的问题不久前。恕我直言,您应该通过它们,例如已经建议作为关联数组(并之前进行所有安全检查)。这样你就可以轻松地重用你的类。

I answered a similar question a while ago. Imho you should pass them e.g. as already proposed as an associative array (and make all the security checks before). In that way you can easily reuse your clases.

扮仙女 2024-08-09 14:32:40

控制器。因为请求数据和模型操作不是一回事。因此,所有其他可能的请求都需要将基于请求数据的逻辑放入模型中,这很糟糕

Controller. Because request data and model manipulation is not the same thing. Putting request data-based logic in model will thus be required for all other possible requests, and thats bad

述情 2024-08-09 14:32:40

这就是我所做的...

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

我主要编写 API,使用 Content-Type: application/json 通过 JSON 传输信息。然而,无论 $_POST 如何填充,这都会起作用(并且在我看来更好)。

无论您在做什么,我建议将 $_POST 超级全局对象转换为对象。在您的模型中,接受单个对象作为参数,并提取属性或子属性。

从那里,只需设置控制器方法以使用面向对象的 $_POST 超全局作为唯一参数来调用模型方法。

Here's what I do...

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

I'm mostly writing APIs which transfer information over JSON with the Content-Type: application/json. However, this will work (and is better in my opinion) no matter how $_POST is being populated.

Whatever it is that you're doing, I suggest turning the $_POST super-global into an object. In your models accept a single object as an argument, and pull off of properties or sub-properties.

From there, just set your controller methods up to call the model methods with your Object Oriented $_POST super-global as the only argument.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文