关于servlet与service分离，自己在写小项目练习时的困惑

Question

为了解耦，学习到要求 servlet 要与 Service 分离（ jsp/servlet 表现层； service 业务逻辑层； Dao 持久化层），但自己在写小项目实践练习时感觉很难受，比如：
用户登录成功之后，应该向 request 域中注入登录成功的 msg，即

request.setAttribute("msg","登录成功");

因为在 jsp 中会有

${requestScope.msg}

可这件事不应该属于业务逻辑吗？而 Service 层中不应该拿到 request 这个东西，只能交给 servlet 去完成吗？
如果说这件事最终影响的是 jsp 层，也就是表示层，所以可以把它交给 servlet 来处理，好吧。那现在我碰上这么一个情况，网站的会员还有不同的权限。登录成功之后我想要把用户的权限信息注入到 session 中

request.getSession.setAttribute("authority","admin");

这该是业务逻辑层的事情了吧？可 Service 层理论上不能接收 request 对象的话应该完成不了这种任务。
而且如果要交给 Servlet 去做的话，相当于 login 方法还要返回一个 User 对象，然后 Servlet 中得到这个 User 对象再获取其 authority 属性值，注入 session 中。。。这个怎么想都觉得是业务逻辑啊！！怎么能让 Servlet 来处理呢！！
就头大，望有前辈能解答一下，谢谢！

Answer 1

代码分层的目的是让你逻辑更清晰，不是强制的割裂，这是一种代码组织方式。

实际中，service 层要处理最复杂的业务本来就是处理输入输出的，必然牵扯到 通过 request，response 获取和输出数据。

如果让你在service层看起来更独立一点，你完全可以把 request和response的能力做一个封装，作为当前上下文的输入输出接口实现，而不是直接操作它们

servlet 是一种程序语言提供的原生手段，不是代码组织方式。 你把代码分层和 servlet 做对比，本身就是不合适的。 servlet 为java的web开发提供了非常方便的封装（不然你还得自己实现http协议）， 你如果阅读了解主流框架，spring mvc之类的， 并不是脱离servlet，只是把 request和response的能力做一个封装 当然还有一些CI的事情。

Answer 2

一直看你在强调业务逻辑,自己怎么方便怎么来才是最重要的,没必要严格遵守那些规范.