在哪里提供验证的逻辑规则答案

【问题标题】：Where to provide logic rules for validation在哪里提供验证的逻辑规则
【发布时间】：2012-08-21 04:50:13
【问题描述】：

我有一个文件导出器，并将字段类型验证为字符串、日期等 + 以及每行的字段计数。

现在，将这种逻辑的规则保存在哪里，以便负责创建 csv 的类是通用的并且与任何业务逻辑解耦，并且如果业务需求发生变化，则导出的类永远不需要修改。

我曾考虑创建用于业务逻辑的第二个类，但这需要以下内容 - 我认为两者同样糟糕：

类内的硬编码规则
要传递给构造函数的规则

似乎没有什么好的解决办法，但这一定是通病吧？

【问题讨论】：

标签： oop design-patterns

【解决方案1】：

像往常一样，这取决于..

数据的责任在于提供者。如前所述，“fileExporter”将导出文件，如果数据提供者被密封，那么显然您将创建一个将断言数据的验证器，随后将断言的数据传递给文件导出器。

如果它不是密封的，你可以将依赖注入其中。

即

class DataProvider(IDataValidator dataValidator, IFileFormat fileFormat){...}
interface IFileFormat { void Export();}
interface IDataValidator { void AsserData(); }
class CSVDataValidator : IDataValidator{...}
class CSVFileExporter : IFileExporter {..}

var dataValidator = new CSVDataValidator();
var iFileFormat = new CSVFileFormat();
var dataProvider = new DataProvider(dataValidator, fileFormat);
var data = dataProvider.Data;
var csvFileExporter = new CSVFileExporter(data)
csvFileExporter.Export();

基本上可能性是无穷无尽的，这取决于你想关闭什么以及你希望在未来扩展什么

我会阅读策略/依赖注入/打开关闭原则

【讨论】：

所以在提供的示例中，datavalidator 和 fileformat 都必须知道 csv 的格式，即字段数等？
哇——现在说得通了。虽然有很多类，但我想这就是为非常可扩展的设计付出的代价

【解决方案2】：

在我看来，您应该尝试使用责任链模式。如果作为参数传递的内容为“有效”，则您的客户端拥有一个验证器对象列表，每个验证器对象实现一个带有方法（即验证）的验证器接口，该方法返回 true。每个组件都有自己的验证标准，但是对于通过其通用接口使用它的客户端来说，它是黑盒的。因此，当您构建系统时，您会实例化您的客户端并注入您需要的验证器。

【讨论】：

所以验证规则是硬编码在验证类里面的？
ValidatorClient 委托一个 Validator 列表来验证内容。如果它们都返回 true，则内容有效。创建 ValidatorClient 的类会注入验证器。见it.wikipedia.org/wiki/Chain-of-responsibility_pattern