这是从服务层组织类的好方法吗？答案

【问题标题】：This is a good way to organize the classes from the service layer?这是从服务层组织类的好方法吗？
【发布时间】：2011-11-05 04:34:30
【问题描述】：

目前我有以下结构：

Model/
    Entities/
    Repositories/
    Proxies/
    Services/
        User/
            Manager.php
            Relations/
                 Friendship.php
        Group/
            Manager.php
            Administration.php
            Posts/
                Manager.php
        ...

由于我使用的是 Doctrine，所以我选择了这种结构，因为每个文件夹对应一个实体。这样组织有什么问题吗？

我想知道您对如何避免将来由于现在组织不当而导致文件夹结构发生变化的意见。有没有更好的方法从服务层组织类？你能推荐什么？谢谢。

【问题讨论】：

标签： php zend-framework doctrine-orm directory-structure service-layer

【解决方案1】：

它看起来像一个完美的有效结构，但是，我可能有两个建议：

我通常将代理放在我的库文件夹之外，因为首先，它是一个不遵循PSR-0 建议的特殊类，其次，您可能需要在进行数据库更新时删除这些类，出于这些原因，我把它们放在/var/tmp/proxies
服务层结构看起来不错，但请确保应用于您的逻辑而不是您的实体，我的意思是，UserService 完全有效地收集用户背后的所有逻辑，但也可以与一些其他实体，因为它们的关系。结论“一个实体！== 一个服务”
我也避免使用复数形式，这有点个人观点，但它有点类似于数据库系统中使用的命名约定，表代表一个实体，因此不应该接受复数形式。顺便说一句，大多数框架（即 Zf/Symfony2/Doctrine2）都使用单数。

要求

如果您决定有一天重构您的结构，请花一两天时间，在所有地方都这样做，或者不这样做。

【讨论】：

谢谢 Guéry，我在持久性 (db) 和实体中使用单数名称，复数文件夹中我只是有点粗心。感谢您对代理的接触，最好的办法是将它们放在一个临时文件夹中，因为它们是由 Doctrine 生成的。一个服务类不一定与一个实体相关，一个例子是一个用户的服务类可能有一个用于 acl 的方法，但这个方法只会充当另一个负责 ACL 的服务类的代理，这是一个很好的做法，对吧？
嗯，我认为这确实取决于您的应用程序，但是，我从未在我的 UserService 中放置任何授权逻辑。想想单元测试，如果你需要使用你的 UserService，你将不得不模拟一个登录的用户，或者根据你的测试编写你的服务，这不是一个好主意。我大部分时间都使用 AuthorizationService 来检查权限，使用 isAllowed() 方法（例如 Zend_Acl）。
每个服务调用都需要更多的代码，但它更灵活 ihmo，你可以让你的 Acl 不受任何资源、角色、特权的影响。当您需要更改权限时，您只需编辑您的 AuthorizationService 或任何相关配置文件。