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