用 PHP 设计服务层类 [英] Designing service layer classes in PHP

问题描述

我最近介绍服务层由 Jani Hartikainen 在关于如何最好地处理 MVC 应用程序中的表单数据的讨论中提供.在 做一些阅读之后 我真的可以看到这种方法的好处.我的问题是:

I was recently introduced to service layers by Jani Hartikainen in a discussion about how to best handle form data in a MVC app. After doing some reading I can really see the benefits of this approach. My question is this:

服务类应该如何构建?

• 首先，user_service() 是适合我的 user() 模型的类名还是其他标准?
• 由于我的服务中的方法只会执行一项任务，认为这些方法始终可以是 静态函数 是否正确?服务类不代表数据，而是一系列动作，所以这似乎很合适.
• 服务方法是否应该只接受一个argument，也就是一个array?

• First, is user_service() an appropriate class name for my user() model or is there another standard?
• Since the methods in my service will only be doing one task, is it correct to think that these can always be a static function? A service class isn't representing data, but rather is a series a actions, so this seems appropriate.
• Should a service method only accept one argument, which would be an array?

假设表单已将数据发布到控制器以保存用户数据:

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

我觉得这是一个很好的方法，因为:

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

• I can add another field to my form and I won't have to update the controller, just the service. It seems right that the controller shouldn't be concerned about what data is being passed, just that it is passed. This keeps my controller small, and the logic in my models.
• If I didn't pass an array, I could setup functions with multiple arguments. For example my function could be update_preferences($firstname, $lastname, $email). This however could make for functions with upwards of 20 arguments (for large forms), and the order would just become terrible to work with.
• I could pass an object, but does that make sense? If I'm creating an object, it should the be the object it represents (the user in this case) right? But does it make sense that the controller instantiates the user object? Isn't that the whole point of the service layer in the first place?
• Maybe there is an argument for having some methods with multiple arguments (when there are just one to three) and some methods that accept an array (when there are lots of fields). This just seems like it could be a nightmare, as you would always have to reference the class to know what that particular method was asking for.

有人对在这里做的正确事情有意见吗?我在正确的轨道上吗?你过去做了什么?非常感谢！

Does anyone have an opinion on what the right thing to do here is? Am I on the right track? What have you done in the past? Thanks a lot!

推荐答案

既然你给我发了一封电子邮件，你也可以回答这个问题 ;)

Might as well answer this since you went as far as sending me an email ;)

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

First, is user_service() an appropriate class name for my user() model or is there another standard?

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

That's acceptable. However, you should rather use one of the established PHP coding conventions, such as the PEAR or ZF conventions. In both cases, class names are UpperCamelCase and method names lowerCamelCase. Using this, the classes would be User and UserService

由于我的服务中的方法只会执行一项任务，认为这些方法始终可以是静态函数是否正确?服务类不代表数据，而是一系列动作，所以这似乎很合适.

Since the methods in my service will only be doing one task, is it correct to think that these can always be a static function? A service class isn't representing data, but rather is a series a actions, so this seems appropriate.

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

No. It's a poor design choice to make methods static - and this applies to most code, not just services. One of the main reasons in case of a service would be that generally your service needs to interact with a data store or another class which represents the data layer (repository, data access object, whatever).

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

When your service has static methods, this means you would need to instanciate your dependencies in your methods. This in turn means that, amongst other things, the code becomes hard to test, as you can't easily replace the dependencies.

对此有一些很好的阅读，例如 here(事实上，该博客上的几乎所有内容都适合软件开发人员阅读)

There's some good reading on this for example here (In fact nearly everything on that blog is good reading for software devs)

服务方法是否应该只接受一个参数，即数组?

Should a service method only accept one argument, which would be an array?

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

This is dependent on what the method does. Assuming your example of processing a form's resultset, then yes this will probably work. In some other case it might be a poor choice.

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

I can add another field to my form and I won't have to update the controller, just the service. [ ... ]

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

If I didn't pass an array, I could setup functions with multiple arguments. [ ... ]

是的，在我看来，您对这两个案例的论证非常适合这个用例.

Yep, your argumentation for these two cases is pretty much spot on for this use-case in my opinion.

我可以传递一个对象，但这有意义吗?如果我正在创建一个对象，它应该是它代表的对象(在这种情况下是用户)，对吗?但是控制器实例化用户对象有意义吗?这不正是服务层的全部意义所在吗?

I could pass an object, but does that make sense? If I'm creating an object, it should the be the object it represents (the user in this case) right? But does it make sense that the controller instantiates the user object? Isn't that the whole point of the service layer in the first place?

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

This depends. For example, if you were using a framework which lets you represent forms as objects (such as the Zend Framework and Zend_Form), you could consider passing the form object straight to the service.

也许有些方法有多个参数(当只有一到三个时)和一些接受数组的方法(当有很多字段时).这似乎是一场噩梦，因为您总是必须引用该类才能知道该特定方法要求什么.

Maybe there is an argument for having some methods with multiple arguments (when there are just one to three) and some methods that accept an array (when there are lots of fields). This just seems like it could be a nightmare, as you would always have to reference the class to know what that particular method was asking for.

您通常应该根据方法的名称使参数至少能猜到一半.在我从事的工作中，我们有一个模型，其中包含企业和产品等，企业可以在其中赞助产品.在 ProductService 中，我们有一个名为 sponsorProduct 的方法，它以业务和产品为参数.您几乎可以猜到需要这两个(如果您熟悉代码库)

You should usually aim to make the parameters at least half-guessable based on the method's name. In something I work on, we have a model which has for example businesses and products, where a business can sponsor a product. In a ProductService, we have a method called sponsorProduct which takes a business and a product as parameters. You can pretty much guess it would take these two (if you were familiar with the codebase anyway)

IDE 通常也可以帮助您解决这个问题 - 它们提供代码辅助，显示 params 函数采用的内容.这是我认为 IDE 在大型项目中非常有用的主要原因之一，因为您无法始终记住某个函数究竟需要什么作为参数.

IDE's generally help you with this too - they provide code-assist which displays what params functions take. This is one of the main reasons I think IDE's are very useful in larger projects where you can't always remember what exactly a certain function needs as parameters.

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

As for parameter count, I think usually you should try to have separate parameters. This allows anyone to easily see what parameters are required by just looking at the function's signature, and allows you to define typehints and default values quite easily.

然而，当你得到如此多的参数时有一点是太多了.这可能在 +5 左右，这取决于它是哪种方法.在这种情况下，您可以考虑使用数组或称为参数对象的东西，它本质上是一个包含调用所有参数的对象.更多关于参数对象的信息这里

However there is a point when you get so many parameters it's too much. This is maybe at +5 or so, depending a bit on what sort of method it is. In this case you can consider using an array, or something called a Parameter Object, which is essentially an object that contains all the parameters for the call. More on parameter objects here

这篇关于用 PHP 设计服务层类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！