Grails-命令对象的专用源文件夹？

从我所读到的内容来看，大多数人要么将命令对象放在控制器内（我不喜欢控制器），要么将它们放在src/groovy文件夹内的某个地方

一、 然而，就像Grails如何为控制器、域、服务等创建特定的文件夹一样，我认为只需为命令对象创建一个新的源文件夹就好了。可以是/grails app/commands，也可以是/src/commands。以这种方式进行布局将有助于鼓励使用命令对象

我有点担心这样做可能会打破一些依赖于特定项目结构约定的grails魔法。在运行了一些快速测试之后，我确实验证了数据绑定和域约束导入似乎仍然正常工作

---

对这种方法有什么想法或反对意见吗

与顶级Grails工件（如域类、服务、taglib等）不同，该框架对命令对象类没有任何特殊功能。例外情况是，如果它们是在控制器源文件中为使用类作为命令对象的控制器定义的，在这种情况下，编译器将自动装配可验证的内容，而不必使用可验证的注释标记该类。如果要在自己的源文件中定义命令对象类，那么如果希望该对象可验证（并非所有命令对象都需要可验证），则需要可验证的注释。有鉴于此，我不认为有一个特殊的位置来定义这些类源文件有任何好处。如果它们没有在控制器源文件中定义，通常的做法是在src/groovy/下定义它们，除非您有充分的理由偏离该约定，否则您可能不应该这样做

命令对象类在Grails中几乎是特殊的类型，但实际上并非如此。您可以将任何内容用作控制器操作的参数。如果有某种原因，您可以使用Log4J提供的类作为命令对象。在我看来，有一个特殊的地方来定义它们并不是很合理

---

我希望这能有所帮助。

拥有一个专用文件夹不是一个糟糕的主意。我通常将它们放在/src/的结构中。我不希望Grails在

src/commands

或

Grails app/commands

中编译类，所以我很惊讶这是可行的。就我个人而言，将命令放在

src/groovy

中它们自己的包层次结构中，为我提供了足够的分离，就像@JoshuaMoore提到的那样，它被放在

src/groovy

中，因为它不是需要放在

/gails-app/

下的grails人工制品。您只需遵循使用

*Command.groovy

的惯例，使用@Validateable，一般来说，使用Command对象作为控制器操作的参数。就是这样。@dmahapatro我很确定命令类可以有任何名称，也就是说，它不需要以

command

结尾，您不必遵循使用*command.groovy的惯例，也不必使用Validateable。两者都是可选的。仅当您希望事物可验证时才使用Validateable（许多事物不可验证，也不需要验证）命令对象的源在控制器的源文件之外定义，该控制器将类用作命令对象，如果您使用的是与数据绑定的特殊参数命名有关的未广泛使用的功能，则只需使用*command.groovy约定，为了更好的选择，Grails2.4中删除了它。谢谢。我没有意识到，当在控制器外部定义时，命令对象后面没有特殊的连接。很高兴知道。作为旁注：在上面的一条评论中，您提到了Grails2.4删除基于参数名的数据绑定的效果。如果我正确阅读了文档，听起来更像是他们在扩展文档，这样您就可以基于更多的命名约定（即在参数名称前加上您希望绑定的对象的名称）拥有多个命令对象中的文档描述了它在2.3.x中的工作原理，中的同一节描述了它在2.4.x中的工作原理。在2.3.x中，特殊参数处理与命令对象类的名称相关联。这并不理想，但有点帮助。在2.4中，我们可以在编译时使用一些技巧，因此我们可以使用方法参数名而不是类型名，这确实是一个更好的解决方案。“我没有意识到，当在控制器外部定义命令对象时，它们后面没有特殊的连接”。。。我不知道你说的是什么意思，但我没那么说。如果“连接”指的是来自Spring应用程序上下文的自动连接依赖项，那么这种情况只发生在框架创建为控制器操作参数的命令对象实例上。如果您自己创建一个，则不会自动布线。如果这不是你所说的连接，那么我不知道我是否同意你的说法，这取决于“连接”的含义。我只是说以“Command”结尾的类不接受特殊处理，任何其他用作控制器arg的类都会起同样的作用。是的。对于2.3.x，名称为*command.groovy的命令对象类与任何其他命令对象类之间行为的唯一区别是在中的“命令对象和请求参数名称”下描述的行为。在2.4.x中，名为*command.groovy的命令对象类与任何其他命令对象类在行为上没有区别。