应用服务层——如何编写API方法接口
人们如何设计他们的服务层接口？
我正在编写一个大型 Web 应用程序（在 PHP 中），我们正在使用 MVC，并编写瘦控制器，例如（伪代码如下）
public savePersonAction() {
$input = filter($_GET);
... input validation ...
$result = $this->_service->savePerson( ? );
... etc
}
服务中的 savePerson 是否应该采用整个 $input 结构或上下文的参数（在 PHP 中，关联数组）？
例如这个 -
public function savePerson(array $input) {
或者应该将所有输入字段分开并提供一个“硬”界面，例如
public function savePerson($title, $firstName, $lastName, $dateOfBirth, ... etc.. for many more) {
谢谢。
保罗
How do people design their service layer interfaces?
I'm programming a large web application (in PHP) and we're using MVC, and programming thin controllers e.g. (pseudo code follows)
public savePersonAction() {
$input = filter($_GET);
... input validation ...
$result = $this->_service->savePerson( ? );
... etc
}
Should savePerson in the service take an argument of the entire $input structure or context (in PHP, an associative array)?
E.g. this -
public function savePerson(array $input) {
or should one separate out all the input fields and provide a "hard" interface e.g.
public function savePerson($title, $firstName, $lastName, $dateOfBirth, ... etc.. for many more) {
Thanks.
Paul
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的 MVC 应用程序的结构如下：
控制器->服务-> ORM/其他库
要回答您的问题，通常在控制器中您将以数组形式获取表单数据，即 $form->getValues() 或类似的东西。就可维护性而言，最好您的服务不使用数组作为参数，这样，如果您向表单添加另一个字段，您只需更新表单和服务，您的控制器就可以保持不变并且仍然可以工作。
所以我认为按照你的第一个例子：
此外，你不应该需要一个“硬”接口，因为你的表单库将负责验证/过滤/清理，所以我们可以假设关联数组将是有效的，加上方法定义使用命名参数会变得非常长。
My MVC applications are structured like this:
Controller -> Service -> ORM/other library
To answer your question, typically in your controller you will be getting form data as an array, i.e. $form->getValues() or something similar. In terms of maintainability it's best if your Services except arrays as arguments, that way if you add another field to a form, you only have to update the form and the service, your controller can remain untouched and still work.
So I think go with your first example:
Furthermore, you shouldn't need a "hard" interface because your form library will take care of validation/filteration/sanitization so we can assume that the associative array will be valid, plus the method definition will get ridiculously long with named parameters.
我将分离出所有输入字段，并在服务中提供一个“硬”接口，例如
它更干净，并且不需要任何假设。
I would separate out all the input fields and provide a "hard" interface in Service e.g.
Its cleaner and there are no assumptions needed.
如果您要遵循 MVC 精神，您的
savePerson方法不应接受原始输入。它不应该直接与来自用户界面的数据格式耦合。相反，它应该接受服务域条款中定义的输入，例如“人”对象。 （这可能只是像 Cobby 建议的关联数组）。控制器的操作方法的工作是将原始输入映射到服务所需的格式。这个额外转换步骤的好处是它将您的服务（模型）与 UI 隔离。如果实现不同的 ui，则无需更改服务接口。您只需要编写新的控制器（当然还有视图）。
虽然像
savePerson($title, $firstName, $lastName...)这样的示例是正确的想法，但当您的方法具有超过 2 或 3 个参数时，这通常是一个坏兆头。您应该能够将相关参数分组到某种更高级别的对象中。If you're going to follow the MVC spirit your
savePersonmethod should not accept the raw input. It shouldn't be directly coupled with the format of the data coming from the ui. Instead it should accept input defined in the terms of your service domain, like a "person" object. (This could just be an associative array like Cobby suggested). It would be the job of the controller's action method to map the raw input to the format required by the service.The benefit of this extra translation step is that it isolates your service (model) from the ui. If you implement a different ui, you don't need to change the service interface. You just need to write new controllers (and views, of course).
While your example like
savePerson($title, $firstName, $lastName...)is the right idea, it's usually a bad sign when you have methods with more than 2 or 3 arguments. You should be able to group related arguments into some kind of higher-level object.