代码之家  ›  专栏  ›  技术社区  ›  user14070

使用Wicket+Spring+Hibernate的三层应用程序。您将如何处理交易?

  •  3
  • user14070  · 技术社区  · 16 年前

    我正在考虑使用 Spring附带的过滤器或拦截器,对我作为开发人员来说似乎是一种方便的方法。如果这是你的建议,你建议使用过滤器还是拦截器,为什么?

    @事务性(只读=真) 等等,从而失去了获得更细粒度事务控制的能力?

    对于如何使用Hibernate和Spring将这种解决方案与三层架构集成,是否有某种最佳实践(因为我想我使用Wicket进行演示的决定应该不重要)?

    如果我使用OSIV,我至少永远不会遇到延迟加载异常,另一方面,我的事务在能够通过在视图中未提交来提交之前也会存活更长时间。

    2 回复  |  直到 16 年前
        1
  •  4
  •   Michiel de Mare    16 年前

    这真的是个人品味的问题。

    就我个人而言,我喜欢在服务层设置事务边界。如果你开始考虑SOA,那么对服务的每次调用都应该是独立的。如果你的视图层必须调用2个不同的服务(我们可以说这已经是一种代码气味),那么这2个服务应该彼此独立,可以有不同的事务配置,等等。在服务之外没有打开的事务也有助于确保在服务之外没有发生任何修改。

    OTOH,您将不得不更多地考虑您在服务中所做的工作(延迟加载、如果需要共同的事务性,则将功能分组到同一服务方法中等)。

    一种可以帮助减少延迟加载错误的模式是在服务层之外使用Value Object。服务应始终加载所需的所有数据并将其复制到VO。你失去了持久对象和视图层之间的直接映射(这意味着你必须编写更多的代码),但你可能会发现你的清晰度有所提高。..

    编辑: 这个决定将基于权衡,所以我仍然认为这至少在一定程度上是个人品味的问题。服务层的事务对我来说更清晰(更像SOA,逻辑明显局限于服务层,不同的调用明显分开,…)。这种方法的问题是LazyLoadingExceptions,可以通过使用VO来解决。如果VO只是持久对象的副本,那么是的,它显然违反了DRY原则。如果你像使用数据库视图一样使用VO,那么VO就是持久对象的简化。这仍然需要编写更多的代码,但它会让你的设计更清晰。如果您需要插入一些授权方案,它会变得特别有用:如果某些字段仅对某些角色可见,您可以将授权置于服务级别,并且永远不会返回不应查看的数据。

        2
  •  2
  •   Michael Pralow    16 年前

    如果我使用OSIV,我至少永远不会

    这不是真的,事实上,很容易遇到臭名昭著的LazyInitialization Exception,只需加载一个对象,并在查看后尝试读取它的属性,具体取决于你的配置,你会得到谎言