我读过后MVC With Lazy Loading,我仍然有一些问题:Spring MVC和ORM延迟加载的最佳实践是什么?
如果我们用第四选择,应该负责的变换过程中的哪个部分?控制器或服务?如果我们使用控制器,将@Transactional引入控制器是否好?
我还看到一个post建议使用不同的查询用于不同的用法。它似乎为不同的目的使用不同的获取组JDO fetchgroup。使用这种方式很好吗?
谢谢。
我读过后MVC With Lazy Loading,我仍然有一些问题:Spring MVC和ORM延迟加载的最佳实践是什么?
如果我们用第四选择,应该负责的变换过程中的哪个部分?控制器或服务?如果我们使用控制器,将@Transactional引入控制器是否好?
我还看到一个post建议使用不同的查询用于不同的用法。它似乎为不同的目的使用不同的获取组JDO fetchgroup。使用这种方式很好吗?
谢谢。
在今天的年龄段,您可以并应该暴露services
作为REST controllers
,并返回适当的域对象,而不是ModelAndView或Spring MVC中的其他此类构造。
更新:澄清:这种方法中没有控制器类我建议。公开服务为@Controller
。将公共方法作为REST公开并在该方法上注释跨国,授权等上下文。因为从API的角度来看,这个公共接口可以为所有类型的客户端提供服务,无论是REST还是直接方法调用。
此外,如果您有专用的控制器和服务,您可能会看到一些业务逻辑立即渗入您的控制器。
我会走得更远,而不是使用选项4,这实际上导致了DTO反模式。
话虽如此,它仍然取决于实体的复杂性。由于它引发的查询,一个拥有许多关联的非常复杂的实体将会成为一个表演大师。然而,您的MVC(JSP)可能实际上在需要时解析关联。 (在全REST完整体系结构的旁注中,这是一个问题。)
我同意今天我们应该使用REST服务。这也是我的意图。但是,我仍然有延迟加载的问题,所以我必须在控制器中使用'@ Transactional'。 –
我在说没有控制器类。将您的服务公开为控制器。 '@ Transactional'应该在服务上使用该方法。 – bhantol
明白了,它似乎是一个解决方案。 –
@Transactional继续服务方法。 – kmansoor
真的没有明确的答案,看看这篇文章,我写了关于这个http://blog.jhades.org/open-session-in-view-pattern-pros-and-cons/ –
@kmansoor如果我只是使用服务方法中的“@ Transactional”,那么实体无法访问Controller中的延迟加载文件。 –