jbl*_*lue 11 php oop model-view-controller zend-framework
您可能听说过Fat Model/Thin Controller与Thin Model/Fat Controller的区别.我最近听说你可以在模型之间的某些逻辑进入服务层之间.这有多常见？你知道(或可以想到)任何说明它的真实例子吗？
Bil*_*win 23
Martin Fowler描述了他的伟大着作"企业应用程序架构模式"的服务层模式.如果你关心的问题就像你问过的那样,你应该读这本书.
我想到的一个用途是管理数据库事务.有些人试图在其域模型中封装启动和提交事务.但是当域模型调用其他尝试启动和提交数据库事务的域模型时,他们会感到困惑.那么哪个模型真正决定是否提交或回滚事务？如果不同客户以不同方式使用给定模型,您会怎么做？
该服务层是一个解决方案,因为这是你可以启动和提交涉及多个领域模型的工作层.
至于这是多么常见,我认为这根本不常见.使用Zend Framework(或任何其他PHP或Ruby框架)的大多数人刚刚从"Active Record解决所有问题"转变为新的闪亮,"Data Mapper解决了所有问题." 这个社区似乎每五年只学习一种新模式.他们暂时不会进入服务层.
来自@ktutnik的评论:
不,服务层模式与存储库模式不同.存储库是关于抽象数据库访问,因此您可以使用像Collection这样的数据库.服务层是关于封装复杂的应用程序操作.
另一种思考它们的方式是它们与域模型的关系.存储库用于域模型和数据库之间.而服务层使用一个或多个域模型.
Service Layer ---> Domain Model(s) ---> Repository ---> DBAL
服务层倡导相对较新,仍然受到各种解释.我认为这意味着拥有一个利用控制器调用的多个域模型的层(我可能会过多地简化它).我最近开发了一个网站,利用这个和我遇到的实际优势是:
功能即服务有助于实现可扩展性.如果您的图像服务最初使用本地服务来完成它的工作,那么将该服务指向另一台服务器或某些第三方变得更容易,而无需进行全面更新
灵活性.在项目的一半时间里,我决定改变一个核心功能,并且能够轻松地完成这项任务.让我快速权衡更新的优缺点.这种灵活性在快速原型设计和灌输一定信心时很有用,因为如果你需要重温一些东西,那就不会成为一场噩梦.
可扩展性.我已经在我的应用程序中确定了我可以预见到将来向其他开发人员或其他小部件,移动应用程序开放的服务.在理论上这样做只是为服务添加身份验证和授权(因为这些功能已经在它自己的层中,我不必花时间尝试将我想要公开的内容与其余的代码库分开).
服务很容易添加和删除(也许这属于早期的一点).我有一个特定于项目中特定阶段的服务(例如,仅邀请阶段),我可以在该阶段结束后删除.
我认为它具有实际优势,实现成功的关键是有一个很好的方法来管理应用程序中的服务.我使用symfony的依赖注入组件