欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  后端开发

如何设计合理的service?

程序员文章站 2022-05-05 10:12:19
...
今天碰到一个bug,最后发现原因应该就是service的设计不当(另一个提问)
那么我们应该如何设计合理的service?有哪些要注意的?什么才是好的service?有哪些的例子可以参考?

回复内容:

今天碰到一个bug,最后发现原因应该就是service的设计不当(另一个提问)
那么我们应该如何设计合理的service?有哪些要注意的?什么才是好的service?有哪些的例子可以参考?

我的解决办法如下,有什么缺点请指教:

Service应该分为2种:1,名词Service; 2, 行为Service
如:UserService 与 RegisterService

对于【名词Service】其里面每个method都必须返回相应的对象,如UserService下的upgrade(uid)就必须返回被升级后的user对象。

对于【行为Service】只对外暴露出一个execute(data),excute(data)必须返回行为成功与否的状态以及被施加这个行为的对象,如RegisterService下的excute(data)就必须返回注册成功与否,以及如果成功了它影响的对象。

通常我们约定对外只调用【行为Service】,再在【行为Service】里调用多个【名词Service】和其他【行为Service】,如在RegisterService::execute(data)里调用UserService::create(), UserService::markNewbee(uid),SendEmailService::execut()等;

【名词Service】中允许调用别的【名词Service】,但不允许调用【行为Service】,如UserService::upgrade不单单可以修改user也可以调用LogService::create来创建log,但不能调用LogoutService::execute()来登出用户。

可以简单的理解为一个Model处理它那张数据库表,一个【名词Service】处理多个Model,一个【行为Service】处理多个【名词Service】,这里【行为Service】也就是设计模式里的facade,可以配合command模式使用。

所有Service的每个method的入参都可以是id或者对象实例,如upgrade()可以接受uid也可以接受user作为入参。

回到我的另一个提问,可以这么写

class AService
{
    function get(aid_or_object)
    {
        if (aid_or_object instanceOf A) {
            return aid_or_object;
        }
        return A.getById(aid);
    }
}

class PService
{
    function get(pid_or_object)
    {
        if (pid_or_object instanceOf P) {
            return pid_or_object;
        }
        return P.getById(pid);
    }
}


class Do2Service
{
    function execute(aid_or_object, pid_or_object = null)
    {
        a = AService.get(aid_or_object);
        if (pid_or_object instanceOf P) {
            p = pid_or_object
        } else {
            p = PService.get(a.pid);
        }
        p.s = 'zz';
        p.save();
        a.save();
        return [:success, a, p];
    }
}

class Do3Service
{
    function execute(pid_or_object)
    {
        p = PService.get(pid_or_object);
        p.s = 'cc';
        p.save();
        return [:success, p];
    }
}

class Do1Service
{
    function execute(pid_or_object)
    {
        p = PService.get(pid_or_object);
        p.s = 'yy' if condition1        
        result, a, p = Do2Servce.execute(p.aid, p) if condition2
        result, p = Do3Servce.execute(p) if condition3

        p.a = 'a';
        p.b = 'b';

        p.save()

        return [:success, p, a];
    }
}

你的问题的本质,是两个“主语”(只是在你的案例中恰好都是service而已)的各自一个“行为”(do1 和 do2)含有了完全相同的一个“行动效果”(修改p.s的值)。
冲突不在于service,而在于行动效果冗余。
试想一下,换一个案例,其中只有一个主语,两个行为(do1 和 do2)都是它的,那么问题也是等价的。
两个行为有重叠的行动效果,实在太常见的了。
关键在于,你怎样界定,哪种重叠是满足需求的?哪种是错误、不合理的?

举一个满足需求的例子:
需求是:p是一个鼠标悬停的tips(界面组件)。先根据鼠标坐标,赋值p.top为一个值。随后,计算tips是否超出了窗口边缘。如果是,则计算tips的top的最大值(因为窗口大小可能会被改变,所以需要计算),然后赋值p.top为该最大值。p.left同理。
这是我做网页前端开发时遇到过的需求。

你的解决办法,大概可以解决你的那一个具体案例,但换成别的情况可能就又不对症了。
在我看来,关键在于,一个行为的源头(往往是事件)所导致一连串行动效果,其中要避免出现重叠;除非需求要求必要的重叠。
这“一连串”的“串法”,是设计上要想清楚的。你已经在朝这个方向努力了,只是关注点稍有偏离。
至于串的过程中的对象(主语/宾语)是不是service、是何种service,倒是没有关系。