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

关注点分离

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

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

在 Java 世界中，这种粗粒度功能的标准打包形式是 Java ARchive (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 为大型应用程序和小型应用程序带来的生产力提升中受益。