Api-Admin-Client应用程序的最佳ZF2体系结构

Question

我有一个使用精益启动方法开发的ZF1项目。我现在准备进入一个更进化的项目，因为我知道我的用户需要什么，但我真的想要开发更好的技术。我决定从ZF1转移到ZF2，这是我所在的位置：

API（客户端） - 我有一个“仅推送”API，用户用来向我发送数据 API（管理员） - 管理员可以使用各种指标和聚合消耗推送的数据

客户端的API很安静，但只是当前进入Redis作业队列，并通过cron进行处理，这消除了客户端等待他们的数据将被插入并且他们的请求被立即返回。

管理员的API目前并不稳定，实际上只是在应用程序内部消耗，我认为这是可以的，因为我不希望有单个页面前端或API消耗前端。我宁愿数据立即由服务器返回。

这给我留下了一个问题，即我是否有一个API服务模块，它提供了所有模型（Doctrine2 ODM POPO），映射器，过滤器和服务层来访问它，然后需要它的控制器可以消费API而不发出HTTP请求（通过服务调用）。

这是结构的正确方法还是存在更精确和可接受的方法？一般情况下，我喜欢服务层，因为测试会更加准确，所有客户端/管理员都使用相同的API（如果它更新，实质上立即更新，因为没有单独的项目）。

Answer 1

我认为你想到的模块不需要有一个自己的构建服务层，它只会转发到另一个服务（比如Doctrine entitymanager或其他的服务），它应该只通过配置向其他模块提供所需的服务DI并封装所需的类（如模型，映射器，过滤器...）。

在我的公司为此目的总是有一个'应用程序'模块（就像它在早期的ZF2教程中）。我不知道这是否仍然是最佳做法，但在维护和结构方面有一些重要的好处。

您应该考虑在“消费”模块（如Client-API或Admin-UI）中定义module dependency。

也值得看看Doctrine库和DoctrineModule的实现，以感受一个模块应该提供什么以及它在何处提供一个库。