三、 片刻思考
  乍看起来，你可能感觉有些奇怪：我们花费了如此巨大的努力去避免在我们的模型类中添加LINQ to SQL属性，而现在我们又把校验器属性添加到相同的类上，为什么能够成功地添加校验器属性却无法添加LINQ to SQL属性呢？

  这基于两个重要的考虑。首先，我们在未来有可能需要进一步更改数据访问技术。例如，我可能需要把LINQ to SQL修改为基于Microsoft Entity Framework或NHibernate的数据访问技术。当有可能在未来需要改变数据访问技术时，我不想把一个特定的数据访问技术硬编码进我们的模型类中。

  然而，在未来我却不可能再去改变处理表单校验的方式。我不想以后再改变表单校验框架。因此，在模型类上添加校验器属性不会影响我们以后可能想更改的其他内容。

  在此，存在两个密切相关的软件设计原则要求我们必须加以考虑：单一责任原则（Single Responsibility Principle）和封装变化原则（Encapsulate What Varies Principle）。这两个原则都警告我们，当我们想改变软件时，我们应该竭尽全力去把以后可能变更的软件部分与我们的代码的其他部分隔离开来。

  如果我们喜欢的话，我们可以把校验器属性与我们的代码的其他部分隔离开来。也就是说，我们能够把Product类再细化为两个类：Product类和ProductValidationModel类。我们不需要改动Product类以便在其中添加校验。我们完全可以把所有的校验器添加到另一个完全相同的ProductValidationModel类上。当我们调用Validation.Validate()方法时，我们可以把ProductValidationModel类而不是把Product类传递到这个方法。

  但是，请注意在此论坛应用程序中我不想把这个Product类再拆分成两个子类，因为这样似乎导致过于复杂（Needless Complexity）。我的确不希望再改变校验框架，因此再作额外的工作并无多大意义。