服务层和控制器:谁照顾什么?

在课上,我们现在正在学习如何构build一个Spring应用程序,即使Spring没有直接参与,我们也学会了如何为DAO和服务层对象创build接口。

如果我错了,请纠正我:DAO层是非常抽象的:它只包含CRUD操作,并进一步用于读取数据(即:获取所有对象,获取特定对象等)

服务层:包含创build事物和删除事物的服务,这是业务逻辑应该在的地方。

现在所有这些在服务层中都是有意义的。 除了“更新”对象。 你只是把一个“更新”function,只保存在您的数据库中的对象? 或者你还需要在那里定义逻辑? 这就是我的困惑所在,我的理解是Spring中的对象只是POJO的。 那么谁来validation数据呢?

比方说,我有一个对象“孩子”它有: NameSurNameGenderPhotoSurName Birthdate字段。 我将如何命名这些服务? 或者你只是让控制器负责validation,这对我来说似乎并不正确。 另一方面,将所有需要调用的服务器委派给服务层也不太合适。

所以基本上只是:帮助我如何定义通过服务层保存对象。

如果你希望控制器能够把变化持久化到一个Child对象,那么传统上你会在服务中有一个名为ChildService.update(Child newchild) ,它将处理调用正确的DAO来保存新版本这个孩子。

控制器可以自由地要求一个孩子的服务,改变周围的领域(可以根据一些用户的input) – 一个理智的devise将使控制器与儿童POJO一起工作,然后要求服务坚持改变。 POJO模型应该对控制器,服务或DAO一无所知,只是简单地按照您的build议持有数据 – 当然,您不希望每次调用setName()setGender()自动导致数据库更新。

相反,控制器和/或服务应该获取一个Child对象,为其工作单元中的对象做所需的任何工作,然后请求服务(然后是DAO)来坚持这些更改。

validation可以在几个层次上进行 – 控制器可能需要validation来自Web用户的任何input,并且服务可能需要validation它具有有效的Child对象,然后才能保留它。 如果您希望以其他身份重新使用此服务(例如公开REST接口,不同的前端等),那么在两层中都进行一定程度的validation尤其有意义。

一般来说,Spring服务是事务性的。 事物进入一个特定的服务方法,因为他们应该在同一个事务中组合在一起。 如果你想从数据库中检索一个对象,把它旋转,并保存新的版本,检索和保存应该在同一个服务方法中。 所以你的服务方法是根据你需要为用户做的应用程序来决定的。

我尝试限制控制器做有关validationhttp参数的工作,决定使用什么参数调用什么服务方法,在httpsession或请求中放什么,redirect或转发什么视图,或类似的与web相关的东西。

就validation而言:validation控制器中的input参数是一件好事,可以确保没有人能够通过虚假input来破坏您的应用程序。 控制器中的validation往往是要确保input在语法上是正确的(包括检测注入攻击),而服务级别validation是关于确保数据库中事物的状态是您所期望的。

所以控制器包含Web框架基础设施代码,服务包含应用程序逻辑代码。