我是否处于分层防泄漏模式？ 我该怎么办？

Question

我被要求向现有系统添加模块。 在研究结构时，我发现了一些“怪异”的东西。 该系统基于struts1。

在一些jsp中，我发现有一些DAO调用来返回实体对象。 在大多数JSP页面中，都有一个<app:validate>标记，该标记将调用DAO来检查访问权限，并且如果不允许，将重定向到登录页面。 有一个accessDA对象，但是它不仅可以进行数据获取，而且还可以进行一些访问权限检查。

我的问题是：

1. 调出DAO是否会导致层泄漏？
2. 应用代码实现是一种好的做法（还是应该在操作类而不是视图中进行检查）？
3. accessDA太胖了吗？
4. 我的新模块应该遵循现有结构吗？

Answer 1

在典型的MVC用法中，应该有明确的关注点分离 。 含义，模型，视图和控制器部分应解耦。 我来回答你的问题

1.喊出DAO是否会导致层泄漏

是。 理想情况下，DAO调用应该在操作/处理程序类中进行。 这样获得的数据被放入请求/会话中，以便稍后由视图呈现层获取。

2，应用标签的实现，这是一个好习惯吗？（还是应该在动作上进行检查而不是查看）

每次访问权限检查都不应有DAO调用。 访问权限应作为用户登录名进行缓存，并应使用上述标记在后续请求中进行检查。 所以在这里，虽然不是直接违规，但不是一个好习惯。

3.accessDA太胖了吗？

是。 看起来是这样。

4.我的新模块应该遵循现有结构吗？

作出上述观察后，我建议不要这样做。

Answer 2

1）海事组织（IMO）是的，但是： 并不是这样的泄漏抽象，正是因为它在标签中。 存在标记以从视图中抽象实现细节。 也有争议的是，在操作中进行访问查找会使操作对仅与视图层相关的内容负责。

将数据访问封装在标签本身中的另一个问题是，如果页面上使用标签的次数很多，则可能需要的数据访问量过多，从而降低了响应时间。 聪明的标签可以通过缓存值来减轻这种情况，或者可以在更深层次上实现缓存。

2）像这样的标记应该对当前用户对象起作用，该对象应该已经封装了用户的权限（可能在登录时）。 也就是说，如果高速缓存的值可以在用户会话期间更改，则使用高速缓存的值来确定访问权限可能还不够。

3）我不知道； 在不知道更多细节的情况下，IMO无法回答。

4）取决于。 多种方式做同一件事可能导致维护方面的噩梦。

如果要根据最佳实践重新构建应用程序，那么可以，新开发应遵循更好的模式。 如果没有的话，IMO会引入多种做同一件事的方式，这会使人更加困惑，并且使追随者变得更加困难，因为他们随后需要决定做某事的方式，确定不同事物之间是否存在功能上的差异方式等等。