作为单身人士的道服务？答案

【问题标题】：Dao Services as Singletons?作为单身人士的道服务？
【发布时间】：2019-02-08 13:25:00
【问题描述】：

我正在使用 Javalin 开发一个网络应用程序。我有多个控制器类为我处理路由。每个控制器都应该与一个 POJO/DB 表类型相关联。例如，我有一个 Employee 控制器来路由和显示与 Employee POJO 相关的页面。 Employee 控制器（在后端）主要引用一个 Employee Dao 服务，然后查询数据库中的 Employee 表。到目前为止一切顺利，对吧？

我的问题是，我的一些前端页面必须包含来自其他表的详细信息，这意味着我正在我的 Employee 控制器中创建其他 DAO 服务的实例，例如，有时我需要 GroupDaoService 和 LocationDaoService 因为几个员工页面也会显示组和位置信息。我想这会占用一点内存，因为每次加载不同的页面时，都会使用一组不同的 DaoService。所以我的问题是，这些 DaoServices 应该是单例吗？有一个 EmployeeDaoService 有意义吗？这些不同的 DaoServices 使用的底层数据库连接池类已经是一个 Singleton。我的 DaoServices 应该遵循同样的模式吗？

将我的 DaoServices 更改为 Singletons 是否有意义？

这是 EmployeeController 的一个示例部分，除了 EmployeeDao 之外，它还需要实现 3 或 4 种其他类型的 DAO，这就是引发这个问题的原因。

`    public static Handler serveUserDetails = ctx -> {
         List<Integer> recCounts = mainSVC.getTotalRecords();
         Map<String, Object> pdata = new HashMap();
         String userID = ctx.pathParam(":id");
         pdata.put("numEvents", recCounts.get(0));
         pdata.put("numSites", recCounts.get(1));
         pdata.put("numUsers", recCounts.get(2));
         pdata.put("user", userSVC.getEmployee(Integer.parseInt(userID)));
         pdata.put("groups", groupSVC.getGroups());
         pdata.put("schedules", schedSVC.getSchedules());
         pdata.put("webuser", W_EMP);
         ctx.render("/templates/userdetail.vtl", pdata);
    };`

【问题讨论】：

标签： java model-view-controller singleton dao javalin

【解决方案1】：

是的，这是有道理的。服务通常是单例的。我认为没有充分的理由在单个节点上的 Web 应用程序中需要多个实例。如果你使用 Spring 进行依赖注入，那么单例已经是默认作用域了。

当然，这假设服务是无状态的，即不持有会话或请求相关数据。

【讨论】：

我的所有服务都需要处理与 Web 用户会话相关的一条状态信息。最后一行 W_EMP 是我的“网络用户”对象，它保存了这些信息。但是，控制器仅将这些信息用于显示目的。有没有一种很好的方法来处理这种有状态的信息并且仍然将 Dao 服务转换为单例？
您不应该将 webuser 作为任何单例组件中的字段，因为 Web 应用程序通常是多线程的。如果你这样做了，用户可能会看到另一个用户的详细信息。数据是只读的并不重要，因为对于不同的线程/用户，它仍然是不同的数据。
注意：控制器传统上是单例的（并且应该是无状态的），原因与服务应该是相同的。
这种模式真的很标准。大多数 MVC 示例应该显示这一点。控制器提供的内容不应存储在控制器内的字段中。它可以从 HTTP 会话（这曾经是相当标准的，但由于可扩展性问题等原因不再常见）、本地存储库（例如数据库）或对远程服务的调用获得。
HttpSession 是将状态与用户关联的标准解决方案。它依靠称为“会话 cookie”的 cookie 来了解会话 ID。 Web 容器（例如 Tomcat）将所有活动会话存储在内存中。如果应用程序在会话中存储大量数据，这可能会成为性能瓶颈。此外，当使用负载平衡或回退节点来提高可伸缩性时，会话很麻烦，因为用户总是需要点击知道他们会话的节点。所以要么需要将请求路由到正确的节点，要么需要迁移会话。痛苦。