在MVC应用程序框架中使用拦截器还是不使用拦截器？
使用拦截器来控制 MVC 框架中的事件流 == 业务逻辑是否与框架耦合或泄漏到框架？
这是人们应该担心的事情吗？除非框架严重损坏或过时，否则似乎不太可能有人会更改 MVC/应用程序框架，对吗？
但如果我遵循相同的逻辑，这是否意味着可以绕过服务层而只拥有胖控制器？唔...
Does using interceptors for controlling the flow of events in a MVC framework == business logic coupled with, or leaked to, the framework?
Is that something one should even worry about? Doesn't seem likely that someone would change the MVC / Application framework unless the framework is severely broken or outdated, right?
But if I follow the same logic, does that mean one can bypass the Service layer and just have fat controllers? hmm...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
仅当您想以纯粹的形式使用 MVC 模式时，您才应该担心它。如果您使用拦截器来控制事件流，您的业务逻辑将不会解耦，如果您想稍后重用它，这不是一件好事。拥有一个胖控制器会损害单元测试控制器的基础。然而，由个人“选择”他或她想要从框架中使用什么以及以什么方式使用？
只是我的2分钱...
You should worry about it only if you want to use MVC Pattern in its pure form. If you are using the interceptors to controlling the flow of the events, your business logic would not be decoupled which is not a good thing if you want to reuse it later. Having a fat controller will hurt the foundation of unit testing controller. However - its upto an individual to 'pick n choose' what he or she wants to use from a framework and in what ways?
Just my 2 cents...