Grails 是一个开发 Web 应用程序快速简便的绝佳框架。您还可以访问大量插件，这些插件提供功能或使与其他系统的集成变得轻松便捷。这都很好，但在本文中，我想讨论一下当您的应用程序增长并开始陷入控制器、域类和其他文件的海洋时会发生什么。

关注点分离

软件架构中最有用的模式之一称为关注点分离。其思想是将与特定功能或关注点相关的所有内容分组到一个独立的单元中。该单元中的代码不应承担任何其他职责。例如，Web 服务的业务逻辑应位于一个类中，而 SOAP 消息的处理应位于另一个类中：业务逻辑和 SOAP 处理是两个不同的关注点。

这种模式的真正优势在于，您可以将这些单元聚合到更粗粒度的关注点中，因此您最终在多个级别上使用该模式。例如，假设上面提到的 Web 服务提供了一种类似博客的功能。您可以将业务逻辑、SOAP 网关以及可能的一个 REST 接口打包到一个可以重用的单元中。

在 Java 世界中，此类粗粒度功能的标准打包形式是 Java 归档 (JAR)。如果您已经是 Grails 开发人员，您就会知道您的 Grails 应用程序可以使用此类 JAR 文件。但它们在处理控制器、域类和其他特殊的 Grails“工件”时无济于事。幸运的是，我们有一个现成的单元可以提供帮助：Grails 插件。

Ryan Geyer 撰写了一篇很棒的文章，演示了如何使用插件提供可重用的域模型以及为什么要这样做。以下是另一个图解形式的示例

我们将博客功能打包到一个插件中，并将支付处理功能打包到另一个插件中。这里的想法是，多个应用程序可能会使用相同的支付处理代码，而某些应用程序也可能需要博客功能。您还可以打包静态资源，以确保所有应用程序都具有统一的外观和风格。这就是品牌插件的用途。这可能包括视图、布局和标签库。

Ryan 的文章展示了如何通过插件安装机制完成所有这些操作，但让我们面对现实吧，这不利于快速反馈开发周期。插件的每次更改都需要您打包插件，然后将其安装到您的应用程序中。幸运的是，还有另一种方法。

就地插件

如果 Grails 可以直接从其开发目录加载插件会怎么样？然后，您无需执行打包和安装插件的中间步骤。实际上，从 Grails 1.1 开始，这在某种程度上就已经成为可能，但随着 1.3 版的发布，它现在已经发展到一个更易于使用的程度。您如何做到这一点？很简单。

假设您有一个简单的应用程序和一个并排位于同一目录中的博客插件

my-app
 +- blog
 +- app

要将博客插件包含到应用程序中，只需将此条目添加到grails-app/conf/BuildConfig.groovy:

grails.plugin.location.blog = "../blog"

所需的前缀是“grails.plugin.location.” - 后面的内容由您决定，但我建议您使用插件的名称。表达式右侧是插件开发目录的路径。请注意，这可以是绝对路径或相对路径。

瞧！当您运行应用程序时，将可以使用所有博客的域类、控制器、视图等。更好的是，如果您在应用程序运行时修改了博客的控制器或视图之一，则会自动获取这些更改。换句话说，您可以像使用应用程序工件一样，使用就地插件工件获得自动重新加载。

因此，使用就地插件，您可以获得关注点分离的好处，但您还可以从正常的 Grails 开发中获得快速反馈开发周期！

此技术在您处理插件时效果很好，但在多个应用程序和开发团队之间扩展性不是很好。幸运的是，您可以轻松删除grails.plugin.location行从BuildConfig.groovy中删除，将插件发布到内部 Maven 存储库如本文所述，然后通过依赖项 DSL 将插件添加为依赖项。

使用插件将应用程序分解为可重用部分是一种非常强大且灵活的技术，它允许团队轻松管理多个应用程序，甚至管理复杂的独立应用程序。如您所见，Grails 通过就地插件机制支持这种方法，该机制允许快速开发和插件依赖项。最重要的是，您可以通过对grails-app/conf/BuildConfig.groovy文件进行快速更改轻松地在两种机制之间进行转换。

我希望本文能激励你们中的一些人尝试这种技术，并从 Grails 的生产力提升中受益，无论是在大型应用程序还是小型应用程序中。