问题描述
对于典型的 Web 3 层应用程序，您认为以下设计有哪些缺陷(以及您的理想架构建议是什么)?
What flaws do you see in the following design, (and what would be your ideal architecture suggestion) for a typical web 3-tier application?
我目前的蓝图方法非常粗略(假设Java、Spring、Hibernate、JSP)
My current blueprint approach is very roughly this (assuming Java, Spring, Hibernate, JSP)
无状态，可能用只读事务包装(以避免惰性初始化异常)，仅通过服务从持久性存储中获取实体，将它们作为模型传递给视图.对它们进行业务逻辑(BL应该只在服务层吗?)，如果需要，传回服务层进行持久化.
Stateless, potentially wrapped with a read only transaction (to avoid lazy init exceptions), get's entities from persistence storage via the service only, passes them to the view as the model. Conducts business logic on them (should the BL be in the service layer only?), passes back to the service layer for persistence if required.
优点:对于只读事务包装 - 只有一个连接，同一持久实体没有冗余命中，更好地利用查询缓存，服务层不应该知道"请求参数，或者是必需的init graph span，避免懒惰的init异常.
Pros: For read-only transaction wrapping - only one connection, no redundant hits for the same persistent entity, utilizes query cache better, service layer shouldn't "know" request parameters, or required init graph span, avoid lazy init exceptions.
缺点:只读事务方法可能有风险，控制器不是理想的业务逻辑悬挂位置......很难做 JUnits(你的输入是一个请求......)
Cons: The read-only transaction approach can be risky, controllers are not the ideal Business Logic hanging place... very hard to do JUnits (your input is a request...)
非事务性(访问非惰性集合/成员会导致惰性初始化异常)
Non transactional (access to non lazy collections / members will result in a lazy init exception)
优点:
视图作者不应仅仅通过点表示法影响应用程序的性能(例如，由于延迟初始化大型集合而导致 N+1 个选择.
The view author shouldn't affect by mere dot notation the performance of the application (e.g. cause N+1 selects due to lazy initializing a large collection.
同样在断开连接的客户端(Flex 或其他富客户端)中，远程延迟初始化要么不受支持，要么就是不明智的做法
Also in disconnected clients (Flex, or other Rich Clients) lazy initialization remotely is either non supported, or just not a smart thing to do
缺点:控制器/服务/DAO 必须为视图仔细准备正确的实体图，并且可能会超调(性能)/欠调(惰性初始化异常).无数的服务器端方法可能会导致混乱，因为实体图可以初始化的排列数量存在笛卡尔积
Cons: the controller / service / DAO must prepare carefully the right graph of entities for the view, and may be overshooting (performance) / undershooting (lazy init exception). a myriad of server side methods can cause clutter as there is a Cartesian product to the number of permutations an entity graph can be initialized
按原样使用持久对象(无数据传输对象)，状态保存在会话中.
Using the persistent objects as is, (no data transfer objects), state is saved in the session.
优点:无需重写 POJO，重用现有实体，会话状态比隐藏字段状态处理更安全.
Pros: no need to rewrite POJOs, reuse of existing entities, session state is more secure than hidden fields state handling.
缺点:不利于断开连接的框架、保存陈旧断开连接对象的风险、锁定问题的风险、覆盖其他人的数据、有时需要乐观锁定.
Cons: Bad for disconnected frameworks, risk of saving stale disconnected objects, risk of locking issues, overriding other's data, requires optimistic locking sometimes.
事务性，不知道请求范围，调用一个 DAO 层来进行实际的持久化存储访问.这是 BL 应该在经典的地方，但似乎 BL 一遍又一遍地泄漏到控制器端.
Transactional, doesn't know the request scope, calls a DAO layer for actual persistence storage access. this is where the BL should classically be, but it seems the BL leaks to the controller side over and over.
包含原子持久化存储门面，不知道BL，或任何上下文
Contains atomic persistence storage facade, ignorant of the BL, or any context
您会在上述架构中修复什么?
What would you fix in the above architecture?
您是否认为(像我一样)这是一种非常常见的方法(有一些细微差别，例如在视图中打开会话等)?或者是你第一次看到它而我做的事情非常错误(或正确)?
Do you think (like me) it is a quite common approach (with some minor differences, such as open session in view, etc)? Or is it the first time you see it and I'm doing something terribly wrong (or right)?
你是如何在你的应用程序中解决它的?您是否也将实体 POJO 用于模型和视图?还是将其连接到更简单的 UI bean(全部已完全初始化且安全)?
How do you solve it in your applications? Do you use your entity POJOs also for your model and view? or do you wire it up to simpler UI beans (all fully initialized and secure)?
这可能是一个主观问题，但我确信有明确的最佳实践设计模式可以集中到一个、两个或三个最大的一般宗教".
This may be a subjective question, but I'm sure there are clear best practice design patters that cluster to one, two or three max general "religions".
推荐答案
总的来说，它看起来是一个非常好的架构.如果您还没有阅读过，我会推荐 Martin Fowlers Patterns of Enterprise Application Architecture，它描述了您问题中的每个主题.
Overall, it seems like a very good architecture. If you haven't already read it, I would recommend Martin Fowlers Patterns of Enterprise Application Architecture, which describe every subject in your question.
从问题中不清楚您期望性能有多大.根据我的经验，性能瓶颈很少出现在你认为的地方，而且越早发现，就越容易改变架构以匹配.
It is not clear from the question how large an issue you expect performance to be. In my experience, the performance bottlenecks are rarely where you think they are, and the sooner you find them, the easier it is to change the architecture to match.
您说得对，可测试性是一个主要问题.我已经使用 Martin Fowlers Passive View 模式取得了一些成功.您还应该查看来自同一站点的 Supervising Controller.
You are right that testability is a major concern. I have used Martin Fowlers Passive View-pattern with some success. You should also take a look at Supervising Controller, from the same site.
这篇关于Web 架构:MVC、Lazy 初始化、Data transfer Objects、Open Session In View，是否有共识方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！