数据校验

在项目中，我们通常都是通过js校验用户数据的正确性，往忽略了服务端的校验，这是很危险的事，比如，我在项目中犯了个错。

      修改帐户密码时，我是通过ajax来判断用户输入的旧密码对不对，如果对，就可以作下一步操作，不对，就提示密码错误，这里对时，我是直接在客户端通过href来跳转的，其实用户可以绕过这里的js校验，直接输入href地址，跳到下一步页面，输入新密码，然后就可以修改成功了，我忽略了在后台也要作密码的正确性验证，才能让其修改。

其实在前端作旧密码校验是为了用户体验，提示他正确或错误，好让他作修改，这里只是第一层关口，只是一个幌子，如果高手识别了这个幌子，我们就要拿出杀手锏，终极验证，在服务器直接对数据的正确性作判断，合法就让他过，否则不通过。

    因此，在项目中，我们时刻要记住，在客户端和服务器端都要作数据的校验，保证程序的健壮性，保证数据的安全

服务端校验应该放在action层还是service层

对于页面提交数据的验证,应该放在action层还是service层?
这两个层各自的具体职责是什么?

---

问题补充：我现在是加了一个验证类，action将接收的多个参数，传给service，service调用验证类中的验证方法对这些参数进行验证。如果有一个数据验证不通过，就向上（service层）抛出一个uncheck exception，且此exception的message为详细的报错信息（如用户名不能为空），service层将不处理该异常，继续抛至action层，action捕获抛出的uncheck exception，并将该exception的message当作错误信息传给页面，请问这么做有没有不妥，或有没有更好的（标准）方法？谢谢！

1、action层即作为控制器，它做的事情就是，拿到用户的参数，判断调用什么业务逻辑方法，然后把业务逻辑方法的返回值再传递给用户，你就可以把他当作一个快递分检站
service就里就做具体的业务逻辑判断，dao里面就写直接跟数据库打交道的东西。
action层负责选择不同的展示UI，为了保证系统能够在不同的UI界面做移植，action不要涉及业务逻辑。

2.我不是来回答的，是来讨论的。

以前我都是放在action里做的。具体如下

• 浏览器提交前需要Javascript先校验下。一是本地速度快；二是用户体验好——都填好了也提交了等了好久服务器却说：错！重填！这个容易涨怒气。
• 简单验证action层同样做一遍，因为总会有“聪明人”会绕过浏览器的检查的。这里的问题是如何保持和前端Javascript的一致性，且不写重复代码?
• 业务逻辑验证，具体逻辑写在service层，组合调用在action层。

处理上，和楼主补充内容基本一致。

• 从dao层就向上抛
• service层可能要做些处理。比如回滚，通知管理员等等根据具体业务。但基本上不会完全吃掉，继续上抛。
• action统一拦截。会简单区分下，比如业务错误，直接报信息；致命错误，直接转向去系统异常等。

但是，现在我有些疑问。
随着HTML5越来越牛叉，服务器端渐渐变成只有service（还没有完全）层了。比如开放个rest接口供浏览器，手机，平板及其他客户端调用。
如果考虑今后的这些扩展， 似乎所有验证都扔action里面比较不妥。至少要能够简单解耦出来才可以...

当然早早考虑太多，走向过度设计的歧路也不好...

追问.

我现在是加了一个验证类，action将接收的多个参数，传给service，service调用验证类中的验证方法对这些参数进行验证。如果有一个数据验证不通过，就向上（service层）抛出一个uncheck exception，且此exception的message为详细的报错信息（如用户名不能为空），service层将不处理该异常，继续抛至action层，action捕获抛出的uncheck exception，并将该exception的message当作错误信息传给页面，请问这么做有没有不妥，或有没有更好的（标准）方法？谢谢！

你这样做相当于把本来action（控制器）的工作转嫁给了service，这样就导致service层还要负责控制跳转的工作。
应该在action中调用验证类中的验证方法对参数进行验证。

如果有一个数据验证不通过，就把详细的报错信息（如用户名不能为空）当作错误信息，然后跳转到错误页面提示错误信息。
如果全部验证通过，就调用合适的service进行后续的处理，然后再跳转到操作成功的页面。

这正是action的典型应用场景。这样service只做业务逻辑的处理，控制跳转由action去做。

而且你那样做，在service层自定义一个异常抛出去，在action中又捕获过来，然后提取异常中的报错信息，不是更加大了工作量吗，多做了无用功。在action中调用校验逻辑，只要根据校验结果就可以知道该怎么处理了（是跳转到错误页面还是继续后续处理）。

4.(1)这个要一分为二的看待. 如果是null之类的判断, 可以放在action. 如果是涉及到业务逻辑(比如不变性约束), 都需要放在Servcie层.
(2)按照MVC模式看, Action层也只是接收http请求, 不涉及到更多的职责. 所以在非常复杂的大型项目中, 分三层: Action->AO->Servcie. 此时可以把一些验证工作放在AO层(当然AO还有其他职责). Action层本身只做接收请求, 然后委派给AO. 

5.通用点的方法是在action和service中间加一层数据的验证，这样可以更好的降低耦合性；
但项目中大多时候是数据和业务的耦合性比较强，所以会在使用到数据的时候在进行验证，例如我们要把页面上传的文件内容入库，如果我们先读一遍+验证，然后再读一遍+存库，这样重复的IO操作会很吃程序的效率(当然这只是举个例子)
推荐的做法是在action和service中间加一层数据的在加工方法，将action收集到的数据进行验证+2次处理，然后传递给service

6.此处假设使用三层架构，struts2 那么此时action本质作为命令/处理器（DispatcherServlet才是真正的控制器 因为分派 和 页面选择都是它做的），

  如果有service，action里边还是应该只做简单的收集数据，然后转发数据到service进行处理，根据相应的返回值（返回值/异常[如果出错了]）选择下一个逻辑视图（result）。
  而且web层 功能越少越好， 即非常薄，why？ 比如明天我要提供webservice 那么如相同逻辑还有重复一遍。
  也就是说，action 按照纯粹的话 应该只做收集数据 转发给service。

  如果验证逻辑非常复杂， service层之上可以再加个验证层 进行数据验证

8.Action作为控制器，根据用户请求选择合适的业务逻辑进行处理，然后根据处理结果返回合适的视图展示给用户。

比如Action收到用户登录请求，

• 如果校验失败则返回给用户一个提示用户名不能为空或过短的页面，
• 如果校验成功但是用户名密码不匹配，则返回一个提示用户名或密码错误的页面，
• 如果用户名密码匹配成功则返回登录成功的页面。

简单的校验可以放在Action里面，因为Action里本就没有很多东西。
如果校验比较多最好是放到service层，但是不要跟其他业务逻辑杂糅在一起，那样就乱了，放到单独的service类中（专做校验）。