在struts2中，基本上有两种方法可以引入验证：你可以这样做
程序化验证基本上涉及在您的操作类上实现接口Validatable，为此需要对方法void validate();进行充实。如果要将验证问题报告给用户，则存在更复杂的接口ValidationAware。
在声明性验证中，每个要验证的操作都会获得自己的验证文件myactionname-validation.xml，其中验证程序使用XML描述语言进行声明。
在我工作的公司，我们使用程序化验证原则，使用小型验证框架（内部编写）来帮助重用常见的验证器模式。我刚读了一本struts2书，但声明性验证是首选的方法。本书提供了很多关于如何设置声明性验证的说明，但它几乎没有触及为什么声明性方法更受欢迎的主题。
我看到一些有时支持声明式XML样式配置的一般参数，但我不能真正看到它们在这里应用：改变这种配置（即验证）是紧密耦合的东西动作处理的模型和用于修改模型上的值的GUI。这不是需要在没有重新编译的情况下“即时”配置的东西。
在struts2中使用声明式样式验证有哪些参数？
是否值得深入研究另一种XML标记方言并烦恼处理单独的validation.xml文件？以编程方式执行它并不容易，并且可能更难以维护，因为Java源代码（或者更确切地说是您选择的IDE）将为您提供重构工具，结构化搜索等，而XML配置支持通常是可以容忍的吗？ / p>
答案 0 :(得分：1)
声明性验证更具可读性，功能强大且可自定义。 在一个编写良好的Web应用程序（良好的DTO或VO定义，每个逻辑操作要执行一个Action）中，您可以通过多种方式共享它。
例如，如果您使用访问者验证程序（从JSP验证对象列表），则将.xml文件放在对象包中（使用对象名称），而不是在操作包中，如果使用在多个Actions中的对象，您只需编写一次验证规则，并重复使用它多少次。
我不是XML配置的粉丝，但是在以旧方式完成了几个项目后，我发现了这种验证的全部潜力，我不会再回来了。
请查看at this，了解您可能想了解的一些提示。
答案 1 :(得分：0)
以编程方式执行此操作不是更容易[...]
不是真的，尽管它也不是那么难。构建错误消息是一个更加手动的过程，但是，大多数人并没有充分利用XML中的功能。
[...]可能更可维护[...]
不是真的，尽管它也不是那么难。
对于具有代码生成的代码库，IMO构建XML比构建Java更容易，但大多数代码库不使用代码生成器。
为了生成人类可读的文档，XML和注释比Java代码更容易处理。
我使用的是一个非常体面的S2支持的IDE，我从来没有想过自己“如果只是我用代码编写它会更容易”，我不记得做了很多，如果有的话，在我的验证中重构，这使我希望它是在代码而不是XML。
重点是在现有机制存在时重复使用：它是一个简单的，已知的机制，集成在框架中，并且每个在S2应用程序上工作的人都知道它是如何工作的。