在 PHP 中设计服务层类

Question

我最近介绍到服务层Jani Hartikainen 讨论如何在 MVC 应用程序中最好地处理表单数据。在阅读一些内容之后 我确实看到了这种方法的好处。我的问题是：

服务类应该如何构建？

• 首先，user_service() 是适合我的 user() 模型的类名吗？还有另一个标准吗？
• 由于我的服务中的方法只会执行一项任务，因此认为这些方法始终可以是静态函数是否正确？服务类并不代表数据，而是一系列操作，因此这似乎是合适的。
• 服务方法是否应该只接受一个参数（即一个数组）？

考虑表单已将数据发布到控制器以保存用户数据：

<?php

    class form_controller extends controller
    {

        public function process_submit()
        {
            if(user_service::update_preferences($_POST))
            {

                echo json_encode(array('success' => true));
            }
            else
            {
                echo json_encode(array('success' => false));
            }
        }

    }

    class user_service
    {

        // Accepts array()
        public static function update_preferences($fields)
        {

            // Check for required fields
            if((
                isset($fields['firstname']) and
                isset($fields['lastname']) and
                isset($fields['email'])
                ) == false
            {
                return false;
            }

            // Update user
            try
            {
                $s = new user();
                $s->set_firstname($fields['firstname']);
                $s->set_lastname($fields['lastname']);
                $s->set_email($fields['email']);
                $s->update();

                return true;
            }
            catch(Exception $e)
            {
                return false;
            }
        }
    }

我认为这是一个很好的方法，因为：

• 我可以向表单添加另一个字段，但我不会必须更新控制器，仅更新服务。控制器不应该关心正在传递什么数据，而只关心它被传递，这似乎是正确的。这使我的控制器和模型中的逻辑保持较小。
• 如果我没有传递数组，我可以设置具有多个参数的函数。例如，我的函数可以是 update_preferences($firstname, $lastname, $email)。然而，这可能会导致函数具有超过 20 个参数（对于大型形式），并且顺序将变得难以使用。
• 我可以传递一个对象，但这有意义吗？如果我正在创建一个对象，它应该是它所代表的对象（在本例中为用户），对吧？但是控制器实例化用户对象有意义吗？这难道不是服务层的全部意义所在吗？
• 也许有一些参数需要使用一些具有多个参数的方法（当只有一到三个参数时）和一些接受数组的方法（当有很多字段时）。这看起来像是一场噩梦，因为您总是必须引用该类才能知道该特定方法的要求是什么。

有人对这里正确的做法是什么有意见吗？我走在正确的轨道上吗？你过去做过什么？多谢！

Answer 1

首先， user_service() 是适合我的 user() 模型的类名还是有其他标准？

这是可以接受的。但是，您应该使用已建立的 PHP 编码约定之一，例如 PEAR 或 ZF 约定。在这两种情况下，类名称均为 UpperCamelCase ，方法名称为 lowerCamelCase。使用它，类将是 User 和 UserService

由于我的服务中的方法仅执行一项任务，因此认为这些方法始终可以是静态函数是否正确？服务类并不代表数据，而是一系列操作，因此这似乎是合适的。

不。将方法设为静态是一个糟糕的设计选择 - 这适用于大多数代码，而不仅仅是服务。服务的主要原因之一是，通常您的服务需要与数据存储或代表数据层的另一个类（存储库、数据访问对象等）进行交互。

当您的服务具有静态方法时，这意味着您需要在方法中实例化依赖项。这反过来意味着，除其他外，代码变得难以测试，因为您无法轻松替换依赖项。

例如这里有一些很好的读物 （事实上，该博客上的几乎所有内容都适合软件开发人员阅读）

服务方法是否应该只接受一个参数（数组）？

这取决于该方法的作用。假设您处理表单结果集的示例，那么是的，这可能会起作用。在其他情况下，这可能是一个糟糕的选择。

我可以在表单中添加另一个字段，并且不必更新控制器，只需更新服务。 [...]

如果我没有传递数组，我可以设置具有多个参数的函数。 [...]

是的，在我看来，您对这两种情况的论证对于这个用例来说非常正确。

我可以传递一个对象，但这有意义吗？如果我正在创建一个对象，它应该是它所代表的对象（在本例中为用户），对吧？但是控制器实例化用户对象有意义吗？这难道不是服务层的全部意义所在吗？

这取决于。例如，如果您使用的框架允许您将表单表示为对象（例如 Zend Framework 和 Zend_Form），您可以考虑将表单对象直接传递给服务。

也许有一些方法有多个参数（当只有一到三个参数时）和一些接受数组的方法（当有很多字段时）。这看起来像是一场噩梦，因为您总是必须引用该类才能知道该特定方法的要求。

通常，您的目标应该是根据方法名称使参数至少有一半是可猜测的。在我从事的工作中，我们有一个模型，其中包含例如企业和产品，企业可以在其中赞助产品。在 ProductService 中，我们有一个名为 sponsorProduct 的方法，该方法将业务和产品作为参数。您几乎可以猜到需要这两个（如果您熟悉代码库的话）

IDE 通常也会帮助您完成此任务 - 它们提供代码辅助来显示参数函数所采用的内容。这是我认为 IDE 在大型项目中非常有用的主要原因之一，在大型项目中，您无法始终记住某个函数到底需要什么作为参数。

至于参数数量，我认为通常你应该尝试使用单独的参数。这使得任何人都可以通过查看函数的签名轻松地了解需要哪些参数，并且允许您非常轻松地定义类型提示和默认值。

然而，当你获得如此多的参数时，就会显得太多了。这可能是 +5 左右，具体取决于它是什么类型的方法。在这种情况下，您可以考虑使用数组或称为参数对象的东西，它本质上是一个包含调用的所有参数的对象。有关参数对象的更多信息此处