介绍

Grails 框架为 Web 应用开发者提供了许多工具和技术，简化了常见应用开发难题的解决。

其中包括许多简化与数据绑定相关的复杂和繁琐问题的方法。总的来说，Grails 通过提供几种将数据映射绑定到对象图的技术，使得数据绑定变得非常简单。

应用开发者必须理解每种技术的含义，以便确定哪种技术最适合并最安全地用于任何给定的用例。

Web 应用数据绑定概述

许多 Web 应用的一个非常常见的任务是接受一组 HTTP 请求参数并将这些参数绑定到一个对象。然后，该对象可能存储在数据库中，用于执行某种计算或用于执行某种应用逻辑。在 Grails 应用中，其中一些操作通常在控制器操作中执行，数据通常绑定到域对象。

考虑一个类似于这样的域类

代码清单 1

class Employee {
    String firstName
    String lastName
    BigDecimal salary
}

应用中可能有一个表单允许更新 firstName 和 lastName 属性。该表单可能不允许更新 salary 属性，该属性可能仅由应用的其他部分更新。

用于更新特定员工的控制器操作可能如下所示

代码清单 2

class EmployeeController {
    def updateEmployee() {
        // retrieve the employee from the database
        def employee = Employee.get(params.id)

        // update properties in the employee
        employee.firstName = params.firstName
        employee.lastName = params.lastName

        // update the database
        employee.save()
    }
}

Grails 可以通过允许类似这样的操作来简化它

代码清单 3

class EmployeeController {
    def updateEmployee() {
        // retrieve the employee from the database
        def employee = Employee.get(params.id)

        // update properties in the employee
        employee.properties = params

        // update the database
        employee.save()
    }
}

这些示例都假设存在名为 firstName 和 lastName 的请求参数。在第一个示例中，每个需要更新的属性都有一行代码，但在第二个示例中，只有一行代码即可处理所有需要更新的属性。

在这个特定示例中，我们只消除了一行代码，但是如果 Employee 对象有很多属性需要更新，则第一个示例会变得更长、更繁琐，而第二个示例将保持不变。

潜在问题

代码清单 3 比代码清单 2 更简洁，需要更少的维护，但它可能并不适合任何特定用例。

更简单的方法的一个问题是它可能允许用户更新应用开发者不打算允许更新的属性。

例如，如果存在名为 salary 的请求参数，则代码清单 2 将忽略该请求参数，但代码清单 3 将使用该参数的值来更新 Employee 对象中的 salary 属性，这可能会导致问题。

应用代码可以使用几种技术来防御此类问题。一种是使用代码清单 2 中所示的方法。另一种是在请求数据绑定时向 Grails 提供白名单或黑名单属性名称。

一种提供白名单的方法如下所示

代码清单 4

class EmployeeController {
    def updateEmployee() {
        // retrieve the employee from the database
        def employee = Employee.get(params.id)

        // update the firstName and lastName properties in the employee
        employee.properties['firstName', 'lastName'] = params

        // update the database
        employee.save()
    }
}

代码清单 4 中的代码只会将 firstName 和 lastName 请求参数绑定到 employee 对象，忽略所有其他请求参数。如果存在名为 salary 的请求参数，它将不会导致 employee 对象中的 salary 属性被更新。

另一种技术是使用添加到所有 Grails 控制器中的 bindData 方法。bindData 方法允许提供白名单和/或黑名单属性名称

代码清单 5

class EmployeeController {
    def updateEmployee() {
        // retrieve the employee from the database
        def employee = Employee.get(params.id)

        // update the firstName and lastName properties in the employee
        bindData(employee, params, [include: ['firstName', 'lastName']])

        // or... bindData(employee, params, [exclude: ['salary']])

        // update the database
        employee.save()
    }
}

数据绑定和依赖注入

上面描述的潜在问题可能会以多种方式导致应用出现问题。一种情况类似于允许在不打算允许更新员工 salary 属性的应用部分更新该属性。该问题出现的另一种方式是，如果对具有从 Spring 应用上下文注入的任何属性的对象执行数据绑定。

考虑这样的代码

代码清单 6

class TaxCalculator {
    def taxRate

    def calculateTax(baseAmount) {
        baseAmount * taxRate
    }
}

class InvoiceHelper {
    def taxCalculator

    def calculateInvoice(...) {
        // do something with the parameters that involves invoking
        // taxCalculator.calculateTax(...) to generate some total
    }
}

假设在 Spring 应用上下文中配置了 TaxCalculator 实例以及 InvoiceHelper 实例。TaxCalculator 实例自动注入到 InvoiceHelper 实例中。

现在考虑这样的 Grails 域类

代码清单 7

class Vendor {
    def invoiceHelper
    String vendorName

    // ...
}

Grails 控制器可能会执行类似这样的操作来更新当前持久化在数据库中的 Vendor

代码清单 8

class VendorController {
    def updateVendor = {
        // retrieve the vendor from the database
        def vendor = Vendor.get(params.id)

        // update properties in the vendor
        vendor.properties = params

        // update the database
        vendor.save()
    }
}

潜在问题在于，它可能无意中允许更新 Spring 应用上下文中的 TaxCalculator 实例中的 taxRate 属性。

如果存在名为 invoiceHelper.taxCalculator.taxRate 的请求参数，则在执行“vendor.properties = params”时，就会发生这种情况。根据应用中的其他一些细节，这可能会导致应用出现意外和有问题的行为。

在 Grails 2.0.2 中，这不会成为问题，因为 Vendor 类中的 invoiceHelper 属性是动态类型的，如下所述，动态类型的属性是不可绑定的，除非它们明确包含在白名单中。如果 invoiceHelper 属性是静态类型的，则它将受数据绑定约束。

在 Grails 2.0.2 之前，代码清单 8 中的代码是有问题的，但可以使用上面描述的白名单或黑名单技术轻松解决。

使用数据绑定构造函数时，会出现相同的另一个问题版本

代码清单 9

class VendorController {
    def createVendor = {
        // create a new Vendor
        def vendor = new Vendor(params)

        // save to the database
        vendor.save()
    }
}

在 Grails 2.0.2 和 Grails 1.3.8 之前，执行“new Vendor(params)”时发生的情况是：创建 Vendor 对象，然后针对 Vendor 实例执行依赖注入，然后执行数据绑定并将参数绑定到实例。

由于事件的顺序，如果 params 包含名为“invoiceHelper.taxCalculator.taxRate”的请求参数，则此代码存在与上面描述的相同问题。

在 Grails 2.0.2 和 Grails 1.3.8 中，事件顺序已更改，因此创建 Vendor 对象，然后针对实例执行数据绑定，然后执行依赖注入。

通过这种事件序列，数据绑定不会修改 Spring bean 中的属性，因为 Spring bean 直到数据绑定发生后才会注入。

对于 Grails 2.0.2 和 Grails 1.3.8 之前的 Grails 版本，管理此问题的一种简单方法如下所示

代码清单 10

class VendorController {
    def createVendor = {
        // create a new Vendor
        def vendor = new Vendor()

        vendor.properties['vendorName'] = params

        // or... bindData(vendor, params, [include: ['vendorName']])
        // or... bindData(vendor, params, [exclude: ['invoiceHelper']])

        // save to the database
        vendor.save()
    }
}

这对于每个域类都没有问题，但对于具有 Spring bean 自动注入的域类来说可能存在问题。顺便说一下，同一组问题也适用于 Grails 命令对象，它们也受数据绑定和自动依赖注入的影响。

Grails 2.0.2 数据绑定改进

Grails 长期以来一直支持所有这些技术。Grails 2.0.2 将包含更多管理数据绑定的灵活性。在 Grails 2.0.2 中，代码清单 4 和 5 中的代码的行为与以前版本完全相同。提供白名单或黑名单时，将遵守它。

但是，当没有提供白名单或黑名单时，例如“employee.properties = params”，Grails 2.0.2 的行为可能会有所不同，具体取决于 Employee 类中的某些细节。

在 Grails 2.0.2 中，数据绑定机制默认情况下将排除所有静态、瞬态或动态类型的属性。为了更精细地控制默认情况下哪些是可绑定的，哪些不是可绑定的，Grails 2.0.2 支持新的 bindable 约束

代码清单 11

class Employee {
    String firstName
    String lastName
    BigDecimal salary

    static constraints = {
        salary bindable: false
    }
}

代码清单 11 显示了如何表示 salary 属性默认情况下不可绑定。这意味着当应用执行类似“employee.properties = params”的操作时，salary 属性将不会受到数据绑定的影响。

如果属性曾经明确包含在白名单中，例如“employee.properties['firstName', 'lastName', 'salary'] = params”，则它将受到数据绑定的影响。

结论

Grails 提供的数据绑定机制允许编写简洁、富有表现力的代码，而无需被大量繁琐的数据绑定相关细节所累。应用开发者必须了解使用这些技术的含义，以便可以实现任何特定用例的最佳方法。

参考资料

• Grails 2.0.2 用户指南
• 数据绑定文档
• bindable 约束文档