这是从服务层组织类的好方法吗?

发布于 2024-12-02 05:55:50 字数 466 浏览 1 评论 0原文

目前我有以下结构:

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

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

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

Currently I have the following structure:

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

Since I'm using Doctrine, I have chosen this structure because each folder corresponds to one entity. Are there any problems in organizing this way?

I would like to know your opinion on how to avoid changes to the folders' structure in the future caused by bad organization now. Is there a better way to organize the classes from the service layer? What can you recommend? Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

把时间冻结 2024-12-09 05:55:50

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

  • 我通常将我的代理放在我的库文件夹之外,因为首先,它是一个特殊的类,不遵循 PSR-0 建议,其次,您在进行数据库更新时可能需要删除这些类,出于这些原因,我将它们放在 /var/tmp/proxies

  • 服务层结构看起来不错,但一定要应用于您的逻辑而不是您的实体,我的意思是,UserService 完全有效地收集用户背后的所有逻辑,但可能由于它们的关系,也可以与其他一些实体一起使用。结论“一个实体!==一个服务”

  • 我也避免使用复数形式,这有点个人观点,但它有点类似于数据库系统中使用的命名约定,一个表代表一个实体,因此不应该接受复数形式。顺便说一句,大多数框架(即 Zf/Symfony2/Doctrine2)都使用单数形式。

  • 最后但最重要的是,无论你现在选择什么结构,都要保持一致,我们永远不会说得足够多,我有时会从其他人那里拿回项目,甚至我不明白他们为什么或如何这样做,我尝试遵循他们的约定,当与团队一起开发项目时,这是一个要求

如果您决定有一天重构您的结构,请花一两天的时间,在每个地方进行重构,或者不进行重构。

It looks like a perfect valid structures, however, I may have two recommendations :

  • I usually put my proxies outside of my library folder, because first, it is a special class which doesn't follow the PSR-0 recommendation, and second, you may need to remove those class when doing database update, for those reasons, I put them in /var/tmp/proxies

  • The service layer structure looks ok, but be sure to apply to your logic and not to your entities, I mean, a UserService is perfectly valid to gather all logic behind a user, but may also be used with some other entities because of their relationship. Conclusion "One Entity !== One Service"

  • I also avoid Plural form, that's a bit personnal point, but it is a bit similar to the naming convention used in Database System, a table represent a entity and therefore shouldn't accept plural forms. By the way, most of the framework (ie. Zf/Symfony2/Doctrine2) use singular.

  • Last but least, whatever structure you choose now, be consistent, we'll never tell it enough, I sometimes take projects back from other people, and even I don't understand why or how they did it like this, I try to follow their conventions, when working on a project with a team, it is a requirement.

If you decide one day to refactor your structure, take a day or two, and do it every where, or don't.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文