使用 Spring 分离表示层和业务层
在我刚刚完成的项目中，我正在努力让分布式事务正常工作。
我们使用 JBoss 的 Arjuna 事务管理器和 Spring 的声明性事务边界来实现这一点。
我们的请求序列如下所示：
browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO
这意味着我们有一个 WAR 来为我们的安全 servlet 提供服务，并有一个 EAR 来为我们的 SLSB 提供服务。
我们的 SLSB 有一个静态初始化块来引导我们的 Spring 应用程序上下文。
我不喜欢技术的混合，但我确实喜欢表示层和业务层的分离，它们可以驻留在不同的物理位置。
我很想知道其他人在使用 Spring 时建议如何分层？
In my just-completed project, I was working getting distributed transactions working.
We implemented this using JBoss's Arjuna Transaction Manager, and Spring's declarative transaction boundaries.
Our request sequence looked like:
browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO
What this meant is that we had a WAR to serve our secured servlet and an EAR to serve our SLSB.
Our SLSB had a static initialiser block to bootstrap our Spring application context.
I don't like the mix of technologies, but I do like the separation of presentation and business tiers, which could reside on different physical locations.
I would be interested to know what others propose to separate tiers when using Spring?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一种非常典型的方法是定义 Web 层、服务层和 DAO 层，并将事务语义附加到服务层。 例如，服务层可能是一堆带有 @Transactional 注释的 POJO。 Web 层可能是 Spring Web MVC 控制器。 在这种方法中，Web 层本质上是使服务层适应 HTTP。 分离效果良好，无需 SLSB。
不过，争论的一个领域是关于域对象，例如 Employee 或 PurchaseOrder 等。 这些跨越应用程序层，并且注释似乎发生的一件事是域对象获得与特定层相关的注释。 因此，您可能在这里有 ORM 注释，但随后使用相同的域对象作为表单支持 bean，以避免并行域/表单对象类。 有些人反对这种做法，认为这违反了架构上的关注点分离。
A pretty typical approach is to define a web tier, a service tier and a DAO tier, and attach transactional semantics to the service tier. The service tier might be a bunch of POJOs with @Transactional annotations, for example. The web tier might be Spring Web MVC controllers. In this approach, the web tier is essentially adapting the service tier to HTTP. Good separation and no need for SLSBs here.
One area of debate though is with respect to the domain objects, like Employee or PurchaseOrder or whatever. These span application tiers and one thing that seems to be happening with annotations is that the domain objects get annotations that are tied to specific tiers. So you might have ORM annotations here but then use the same domain object as a form-backing bean as a way to avoid parallel domain/form object classes. Some people object to that as violating architectural separation of concerns.
仅仅为了作为外观的 SLSB 需要一个 EJB3 应用服务器对我来说似乎不值得付出努力。 您没有理由不删除它并让您的 servlet 直接与 Spring 一起工作。 您可以将 ContextLoaderListener 添加到 WAR 中以加载 ApplicationContext，然后添加 WebApplicationContextUtils 来获取它。 或者，如果您需要做的事情超出了 Servlet 本身允许的范围，您可以使用 SpringMVC、Struts 或其他 Web 技术。
Requiring an EJB3 app server just for a SLSB that is a facade doesn't seem like it's worth the effort to me. There is no reason you couldn't just remove that and have your servlet work directly with Spring. You can add the ContextLoaderListener to the WAR to load your ApplicationContext and then WebApplicationContextUtils to get at it. Alternatively you could use SpringMVC, Struts or other web technologies if you need to do more than what the Servlet on its own will allow for.