对于典型的Web 3层应用程序，您在以下设计中看到哪些缺陷（以及您的理想体系结构建议）？

我当前的蓝图方法大致就是这样（假设Java，Spring，Hibernate，JSP）

控制者

无状态的，可能包裹着只读事务（以避免延迟的init异常）的状态，仅通过服务从持久性存储中获取get的实体，然后将它们作为模型传递给视图。在它们上执行业务逻辑（BL应该仅在服务层中吗？），并在需要时传递回服务层以进行持久化。

优点 ：对于只读事务包装-
仅一个连接，同一持久实体没有冗余命中，更好地利用了查询缓存，服务层不应“知道”请求参数或所需的初始化图范围，避免出现惰性初始化异常。

缺点 ：只读事务处理方法可能有风险，控制器不是理想的Business Logic挂架…很难做到JUnits（您的输入是请求…）

视图

非事务性（访问非惰性集合/成员将导致惰性初始化异常）

优点 ：

• 视图作者不应仅通过点符号来影响应用程序的性能（例如，由于懒惰初始化大型集合而导致N + 1选择）。

• 另外，在断开连接的客户端（Flex或其他Rich Client）中，不支持远程懒惰初始化，或者这不是明智的选择

缺点 ：控制器/服务/
DAO必须为视图仔细准备正确的实体图，并且可能是过冲（性能）/欠冲（惰性初始化异常）。大量的服务器端方法可能导致混乱，因为存在可以对实体图进行初始化的排列数量的笛卡尔乘积

模型

按原样使用持久对象（不使用数据传输对象），将状态保存在会话中。

优点 ：无需重写POJO，重用现有实体，会话状态比隐藏字段状态处理更安全。

缺点 ：不利于断开的框架，保存陈旧的断开的对象的风险，存在锁定问题的风险，覆盖其他人的数据，有时需要乐观锁定。

服务

事务性的，不知道请求范围，调用DAO层进行实际的持久性存储访问。这是BL的经典配置，但是BL似乎一遍又一遍地泄漏到控制器端。

道

包含原子持久性存储外观，BL的无知或任何上下文

最后，问题是：

您将在上述架构中解决什么问题？

您是否认为（像我一样）这是一种非常普遍的方法（有一些细微的差异，例如公开会话等）？还是您第一次看到它，而我做某件事却完全错误（或正确）？

您如何在应用程序中解决它？您是否也将实体POJO用于​​模型和视图？还是将其连接到更简单的UI Bean（均已完全初始化且安全）？

这可能是一个主观的问题，但是我敢肯定，存在明显的最佳实践设计模式，它们可以聚集到一个，两个或三个最大的一般“宗教”上。