在一个常见的 MVC 设计的应用程序中，让服务层依赖于用户 session 是不是一个坏主意？假设有一个服务方法可以从数据库中获取一些对象，并且您希望根据调用的初始化者返回不同的结果——例如，管理员可能会得到 10 行对象，而普通用户可能只会得到 7 行因为最后 3 个是“仅限管理员”的对象。解决这个问题的几种方法是:
- 引入一个新的方法参数，其中包括调用用户。无依赖性但很麻烦，必须在许多方法中输入用户参数。
- 针对不同的用户角色制定不同的方法(具有多种结果)。也没有依赖性，但有很多方法基本上做同样的事情，这增加了代码重复的风险。
- 让该方法从存储当前用户 session 的静态上下文中的 ThreadLocal 变量中读取。此变量在每个请求之前设置。
最近，我开始越来越多地使用最后一种方法，因为它提供了一个干净的界面并且感觉非常实用。过滤器确保当前线程始终具有用户集。这是糟糕的设计吗？我相信有些人会认为这是从服务层到 Web 层的依赖关系，尽管我个人认为它们是非常不耦合的。最大的后果是一个方法的行为会根据另一个类的状态而有所不同，这可能是好事也可能是坏事。
您对此有何看法？如果这是一个糟糕的解决方案，那么什么是更强大的解决方案？
最佳答案
我强烈建议不要使用 ThreadLocal 风格的方法——它似乎有太多“全局变量”的设计味道。这有很多问题，最值得注意的是:
- 您的代码变得更难测试，因为您在测试前需要设置越来越多的隐式全局状态的滑坡
- 您无法清楚地看到某段代码正在使用哪些参数。这可能会让维护者感到非常困惑，或者如果您在几个月后返回代码。
- 如果您将工作交给不同的线程，它可能会导致非常严重的错误/复杂性。您已经有效地使您的代码执行取决于它在哪个线程上运行……可能会出什么问题？ :-)
- 您正在创建循环依赖(服务层<->用户界面层)。从来都不是一个好主意，你应该尽量让依赖关系只以一种方式流动(几乎总是用户界面层 -> 服务层)
在其他两种方法之间，我认为“视情况而定”:
- 如果用户本质上是数据模型的一部分(例如，您有一个社交图数据库)，那么将用户作为参数传递似乎很自然。
- 如果用户数据仅用于身份验证等前端内容，那么我倾向于尽量减少对特定用户详细信息的依赖，而是为不同的角色创建不同的方法(或等效地添加“角色”参数)。
另一种选择是将“上下文”对象传递到包含一组相关 session 数据(即不仅仅是用户名)的服务层。如果您想最大程度地减少参数膨胀，这可能很有意义。请注意它会变成一种“绕过”良好分层原则的方法。如果它只是“数据”那么它可能没问题，但是一旦人们开始在上下文中传递回调对象/UI 组件，那么您可能会变得有点困惑......
关于java - 使您的业务(服务)层依赖于用户 session 是不是糟糕的设计？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12247044/