是 MVC +服务层在 zend 或 PHP 中常见？
您可能听说过胖模型/瘦控制器与瘦模型/胖控制器的区别。我最近听说，可以在两者之间添加一些东西，将模型中的一些逻辑放入服务层。这种情况有多常见？您知道（或能想到）任何可以说明这一点的真实例子吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
您可能听说过胖模型/瘦控制器与瘦模型/胖控制器的区别。我最近听说，可以在两者之间添加一些东西，将模型中的一些逻辑放入服务层。这种情况有多常见？您知道（或能想到）任何可以说明这一点的真实例子吗？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
请参阅 ZFEngine，它是 ZF 上的 cmf，具有服务层实现
See ZFEngine it's cmf on ZF with service layer realisation
服务层的倡导相对较新，并且仍然受到各种解释的影响。我认为这意味着有一个层利用控制器调用的多个域模型（不过我可能过于简化了它）。我最近开发了一个利用此功能的网站，我遇到的实际优势是：
功能即服务有助于提高可扩展性。如果您的图像服务最初使用本地服务来完成工作，那么将该服务指向另一台服务器或某个第三方就会变得更加容易，而无需进行全面更新
灵活性。项目进行到一半时，我决定更改一个核心功能，并且能够轻松地做到这一点；让我能够快速权衡更新的利弊。这种灵活性在快速原型设计和灌输一定的信心时非常有用，因为如果您需要重新审视某些东西，它不会是一场噩梦。
可扩展性。我已经在我的应用程序中确定了我可以预见将来向其他开发人员或其他小部件、移动应用程序开放的服务。理论上，这样做只需向服务添加身份验证和授权（因为这些功能已经在它自己的层中，我不必花时间尝试将我想要公开的内容与代码库的其余部分分离） ).
服务很容易添加和删除（也许这属于前面的观点之一）。我有特定于项目中特定阶段（例如仅限邀请阶段）的服务，一旦该阶段结束，我就可以删除这些服务。
我认为它具有实际优势，并且成功实施的关键是有一个好的方法来管理应用程序中的服务。我使用 symfony 的 依赖注入组件
Service layer advocacy is relatively new and still subject to a variety of interpretations. I think it means having a layer that leverages multiple domain models which the controllers call (I may be simplifying it too much though). I recently developed a website making use of this and practical advantages I've encountered are:
Features as a service helps with scalability. If you have an image service that initially uses the local service to do it's work it becomes easier to have that service point to another server or some 3rd party without having to make sweeping updates
Flexibility. Half way through the project I decided to change a core piece of functionality and was able to do so painlessly; allowing me to quickly weigh the pros and cons of the update. This flexibility is useful when rapid prototyping and instills a certain confidence because if you need to revisit something it's not going to be a nightmare.
Extensibility. I have already identified services in my application what I can forsee opening to other developers or other widgets, mobile apps in the future. Doing so in theory is just a matter of adding authentication and authorization to the service (because the features are already in it's own layer and I don't have to spend time trying to decouple what I want to expose from the rest of the code base).
Services are easy to add and drop (maybe this belongs with one of the earlier points). I have services that a specific to a specific stage in the project (e.g. invite only stage) that I can drop once that phase is over.
I think it has practical advantages and a key to success in implementation is having a good way to manage the services in the application. I use symfony's dependency injection component
Martin Fowler 在他的伟大著作 服务层模式.com/books.html#eaa" rel="noreferrer">企业应用程序架构模式。如果您关心像您提出的问题，您应该阅读这本书。
我想到的一种用途是管理数据库事务。有些人尝试将启动和提交事务封装在他们的域模型中。但是，当域模型调用其他也尝试启动和提交数据库事务的域模型时，他们会感到困惑。那么哪个模型真正决定事务是提交还是回滚？如果不同的客户以不同的方式使用给定的模型，您该怎么办？
服务层是一个解决方案，因为您可以在该层中启动和提交涉及多个域模型的工作。
至于这种现象有多普遍，我认为根本不普遍。大多数使用 Zend Framework（或任何其他 PHP 或 Ruby 框架）的人刚刚从“Active Record 解决了一切”转向了新的闪亮的“Data Mapper 解决了一切”。这个社区似乎每五年才学习一种新模式。他们暂时不会进入服务层。
重新评论@ktutnik：
不，服务层模式与存储库模式不同。存储库是关于抽象数据库访问，因此您可以像集合一样使用数据库。服务层是关于封装复杂的应用程序操作。
思考它们的另一种方式是它们与领域模型的关系。存储库用于域模型和数据库之间。而服务层使用一个或多个领域模型。
Martin Fowler describes the Service Layer pattern of his great book Patterns of Enterprise Application Architecture. If you care about questions like the one you asked, you should read this book.
One use that comes to my mind is managing database transactions. Some people try to encapsulate starting and committing transactions in their domain models. But then they get confused when domain models invoke other domain models that also try to start and commit db transactions. So which model really gets to decide if a transaction is committed or rolled back? And what do you do if a given model is used in different ways by different clients?
The Service Layer is a solution for this, because this is the layer in which you can start and commit work that involves multiple domain models.
As for how common this is, I don't think it's common at all. Most people using Zend Framework (or any other PHP or Ruby framework) have just barely moved from "Active Record solves everything" to the new shiny, "Data Mapper solves everything." It seems this community learns only one new pattern every five years. They won't get to Service Layer for a while.
Re comment from @ktutnik:
No, the Service Layer pattern is different from Repository pattern. Repository is about abstracting database access so you can use a database like a Collection. Service Layer is about encapsulating complex application operations.
Another way of thinking about them is their relationship to the Domain Model. The Repository is used between the Domain Model and the database. Whereas the Service Layer uses one or more Domain Models.