我被要求向现有系统添加一个模块。在研究结构时，我发现了一些"奇怪"的东西。该系统基于结构1。
在一些jsp中，我发现有一些DAO调用来返回实体对象。在大多数JSP页面中，都有一个<app:validate>标记，它会调用DAO来检查访问权限，如果不允许，它会重定向到登录页面。有一个accessDA对象，但它不仅可以提取数据，还可以进行一些访问权限检查。
我的问题是：
- 在视图中调用DAO是否会导致层泄漏
- 应用程序标签的实现是一个很好的实践吗（还是应该在动作类而不是视图中进行检查）
- accessDA太胖了吗
- 我的新模块应该遵循现有结构吗
1）IMO是的，但是：它不是这样的泄漏抽象，正是因为它在标签中。标记的存在是为了从视图中抽象实现细节。同样有争议的是，在操作中进行访问查找会使操作负责仅与视图层相关的内容。
将数据访问封装在标签本身中的另一个问题是，如果页面上有许多标签的使用，则可能会有超出必要的数据访问，从而减慢响应时间。一个聪明的标签可以通过缓存值来缓解这种情况，或者缓存可以在更深的层次上实现。
2）这样的标记应该针对当前用户对象，该对象应该已经封装了用户的权限（可能在登录时）。也就是说，如果访问权限在用户会话期间可能发生更改，那么使用缓存值来确定访问权限可能是不够的。
3）我不知道；如果不知道更多的细节IMO，这是不可能回答的。
4）取决于。以多种方式做同样的事情可能会导致维护噩梦。
如果要根据最佳实践重新构建应用程序，那么新的开发应该遵循更好的模式。如果没有，IMO会更困惑于引入多种方法来做同一件事，这会让那些遵循的人更加困难，因为他们需要决定用哪种方法做某事，确定不同方法之间是否存在功能差异，等等
在典型的MVC使用中，应该有一个明确的关注点分离。含义、模型、视图和控制器部分应解耦。让我回答你的问题
1.调用DAO是否会导致层泄漏
是的。理想情况下，DAO调用应该在操作/处理程序类中。这样获得的数据被放入请求/会话中，稍后由视图渲染层拾取。
2.应用程序标签的实现，这是一个好的实践吗？（或者应该在动作cla ss而不是在视图中进行检查。）
不应该在每次访问权限检查时都有DAO调用。访问权限应在用户登录时缓存，并且应使用上述标签。所以在这里，虽然不是直接违反，但不是一个好的做法。
是accessDA太胖了吗
是的。看来是这样。
4.我的新模块应该遵循现有结构吗
在做出上述观察后，我建议不要这样做。