java我在层泄漏反模式中吗？我该怎么办？

Question

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

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

我的问题是：

1. 调用视图中的DAO是否会导致层泄漏
2. 应用标签的实现是一个好的实践吗（或者它应该在动作类而不是视图中进行检查）
3. 这件衣服太胖了吗
4. 我的新模块是否应遵循现有结构

Answer 1

1）我是的，但是：它本身不是一个泄漏的抽象，正是因为它在标签中。标记的存在是为了从视图中抽象实现细节。还有争议的是，在操作中执行访问查找会使操作负责一些仅与视图层相关的事情

将数据访问封装在标记本身中的另一个问题是，如果页面上有许多标记的使用，那么可能会有更多的数据访问，从而降低响应时间。聪明的标记可以通过缓存值来缓解这一问题，或者缓存可以在更深的层次上实现

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

3）我不知道；如果不知道更多的细节，这是不可能回答的

4）视情况而定。以多种方式做同样的事情可能会导致维护噩梦

如果需要根据最佳实践重新构建应用程序，那么新的开发应该遵循更好的模式。如果没有，在我看来，引入多种方法来做同一件事会让人更加困惑，并使那些遵循的人更加困难，因为他们需要决定采用哪种方法来做某事，确定不同方法之间是否存在功能差异，等等

Answer 2

在典型的MVC使用中，应该有一个明确的Separation of Concerns。含义、模型、视图和控制器部分应解耦。让我回答你的问题

1。调用DAO是否会导致层泄漏

对。理想情况下，操作/处理程序类中应该有and和DAO调用。这样获得的数据被放入请求/会话中，以便稍后由视图渲染层拾取

2。应用程序标签的实现，这是一个好的实践吗？（或者它应该在动作课堂而不是视图上进行检查。）

不应该在每次访问权限检查时都有DAO调用。访问权限应缓存为用户登录，并在后续请求中使用 前面提到的标签。所以在这里，虽然不是直接违反，但不是一个好的做法

3。这是不是太胖了

对。看来是这样

4。我的新模块是否应遵循现有结构

在提出上述意见后，我建议不要这样做