使用哪一个：OpenSessionInViewInterceptor 还是 OpenSessionInViewFilter？
我很难决定使用哪个“在视图中打开会话”：使用 Spring MVC 的拦截器配置 OpenSessionInViewInterceptor 或在 web.xml 的过滤器中配置 OpenSessionInViewFilter？根据我的研究，它们的作用几乎相同，但我试图理解每种类型的差异和用法。
两者之间最大的区别是对于无法在 web.xml 中使用过滤器的用户（例如 servlet 2.2 及更早版本），他们唯一的选择是使用 OpenSessionInViewInterceptor。不知何故，我倾向于拦截器只是因为我必须为我的项目创建一个自定义拦截器，所以我正在考虑将所有这些“过滤器”分组在 Spring MVC 配置文件中，而不是在 web.xml 和我的自定义中使用 OpenSessionInViewFilter Spring MVC 配置文件中的拦截器。这确实是一种决定使用哪一个的蹩脚方法，我的好奇心在这里杀死了我。
有人可以分享你对此的想法吗？大家都用哪一款呢？
谢谢。
I'm having a hard time deciding which "Open Session In View" to use: configuring OpenSessionInViewInterceptor using Spring MVC's interceptor with or configuring OpenSessionInViewFilter in web.xml's filter? From what I have researched, they do pretty much the same thing, but I'm trying to understand the difference and the usage of each type.
The biggest difference between the two is for folks who can't use a filter in web.xml (say, servlet 2.2 and earlier), their only option is to use OpenSessionInViewInterceptor. Somehow, I'm leaning towards the interceptor simply because I have to create a custom interceptor for my project, so I'm thinking of grouping all these "filters" in Spring MVC config file rather than having OpenSessionInViewFilter in web.xml and my custom interceptor in Spring MVC config file. It's really a lame way to decide which one to use, and my curiosity kills me here.
Can anyone share your thoughts about this? Which one do you guys use?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如你所说，两者或多或少是等价的。 Spring 提供了这两种方法，以便您可以选择最适合您现有应用程序的一种。
如果您使用 Spring MVC，那么使用拦截器是有意义的，因为它更容易配置并且与 Spring MVC 更好地集成。
但是，如果您不使用 Spring MVC，而仅在业务逻辑级别使用 Spring，那么拦截器就不是真正的选择，而过滤器就变得更合适。由于过滤器不由 Spring 管理，因此更难配置它们以与 Spring 集成，但这就是权衡。
As you say, the two are more or less equivalent. Spring provides them both so that you can pick the one that fits best with your existing application.
If you use Spring MVC, then it makes sense to use the interceptor, since it's easier to configure and better integrates with Spring MVC.
However, if you don't use Spring MVC, and only use Spring at the business-logic level, then the interceptor isn't really an option, and the filter becomes more appropriate. Because filters are not managed by Spring, they're harder to configure to integrate with Spring, but that's the trade-off.
如果您有任何不会通过 spring 控制器的请求，即通过自定义 servlet 的遗留代码，或者直接命中的 jsp，那么过滤器将覆盖这些请求并确保它们被包装在会话中。拦截器不会覆盖这些请求，因为 Spring DispatcherServlet 不会接收这些请求。
If you have any requests that are not going to go through a spring controller, i.e. legacy code that goes through a custom servlet, or jsp's that are hit directly, then the filter will cover those and make sure they get wrapped in a session. The interceptor will not cover those since those requests will not get picked up by the spring DispatcherServlet.