对于典型的 Web 3 层应用程序，您在以下设计中看到了哪些缺陷(以及您理想的架构建议是什么)？
我目前的蓝图方法非常粗略(假设是 Java、Spring、Hibernate、JSP)
Controller
无状态，可能用只读事务包装(以避免惰性初始化异常)，仅通过服务从持久性存储中获取实体，将它们作为模型传递给 View 。对它们执行业务逻辑(BL 应该仅在服务层中吗？)，如果需要则传回服务层以进行持久化。
优点:对于只读事务包装 - 只有一个连接，同一持久实体没有冗余命中，更好地利用查询缓存，服务层不应该“知道”请求参数，或者需要初始化图跨度，避免惰性初始化异常。
缺点:只读事务方法可能存在风险， Controller 不是理想的业务逻辑悬挂位置...很难实现 JUnit(您的输入是请求...)
查看
非事务性(访问非惰性集合/成员将导致惰性初始化异常)
优点:
View 作者不应仅通过点符号来影响应用程序的性能(例如，由于延迟初始化大型集合而导致 N+1 选择。
同样在断开连接的客户端(Flex 或其他富客户端)中，远程延迟初始化要么不受支持，要么就是不明智
缺点: Controller /服务/DAO 必须为 View 仔细准备正确的实体图，并且可能会过冲(性能)/下冲(惰性初始化异常)。无数的服务器端方法可能会导致困惑，因为实体图可以初始化的排列数量存在笛卡尔积
型号
按原样使用持久对象(没有数据传输对象)，状态保存在 session 中。
优点:无需重写 POJO，重用现有实体， session 状态比隐藏字段状态处理更安全。
缺点:不利于断开连接的框架、保存过时的断开连接对象的风险、锁定问题的风险、覆盖其他数据的风险、有时需要乐观锁定。
服务
事务性，不知道请求范围，调用 DAO 层以进行实际的持久性存储访问。这是 BL 的经典位置，但似乎 BL 一次又一次地泄漏到 Controller 端。
道
包含原子持久性存储外观，不知道 BL 或任何上下文
最后，问题:
你会在上面的架构中修复什么？
您是否认为(像我一样)这是一种很常见的方法(有一些细微差别，例如在 View 中打开 session 等)？或者这是您第一次看到它而我做错了(或正确)的事情？
您如何在您的应用程序中解决它？您是否也将您的实体 POJO 用于您的模型和 View ？还是将其连接到更简单的 UI bean(全部完全初始化且安全)？
这可能是一个主观问题，但我确信有明确的最佳实践设计模式可以聚集到一个、两个或三个最大的一般“宗教”。
最佳答案
总的来说，这似乎是一个非常好的架构。如果您还没有读过它，我会推荐 Martin Fowlers Patterns of Enterprise Application Architecture，它描述了您问题中的每个主题。
从问题中不清楚您期望性能有多大的问题。根据我的经验，性能瓶颈很少出现在您认为的位置，您越早找到它们，就越容易更改架构以匹配。
您说得对，可测试性是一个主要问题。我用过 Martin Fowlers Passive View -模式取得了一些成功。您还应该从同一站点查看 Supervising Controller。
关于hibernate - Web 架构 : MVC, Lazy initialization, Data transfer Objects, Open Session In View，有没有统一的做法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1969278/