Question

这有多糟糕？我的教授目前正在要求我这样做，这违背了我被告知的一切。任何人都可以举例说明为什么你不应该这样验证？（在asp网页的get / set方法中使用正则表达式）

更多信息：

以下是他希望我们做的代码：在财产：

public String FName
{
    get
    {
        return _fName;
    }
    set
    {
        if (validateName(value.ToString()))
            _fName = value;
    }
}

我正在调用的方法：

public static bool validateName(String name)
    {
        bool isGood = true;

        Regex regex = new Regex("^[A-Z]");
        if (!regex.IsMatch(name))
            isGood = false;

        return isGood;
    }

Answer 1

一般来说，这并不好，因为按原样验证，也假设失败。

所以问题是：

在constructor代码执行期间，您打算如何处理错误？？
如果您在constructor中收到例外，该怎么办？之后物体的状态是什么？

这就是为什么一般来说这是一种不好的做法。要遵循的好方法是：

构造对象
运行验证

但这些是指南，您可以根据自己的方便自由制动它们。所以，在你的教授的帮助下，应该说，他问了这个问题：

或者带给你一些想法
或教你一些东西

所以按照他的路径，试着理解他为什么要求以这种方式编写代码。

Answer 2

这取决于你的验证意义，保护条款在构造函数中是很常见的做法，例如

if(param1 == null) 
     throw new ArgumentNullException("param1");

它有助于确保您的对象处于一致状态，以便以后使用（防止您在使用时必须检查）。

您还可以在属性（您的情况似乎是）和方法上使用保护子句，以确保您的对象始终处于一致状态。

Answer 3

在回复您的更新时，我发现这真的很烦人，例如：

var a = new yourObject();
a.FirstName = 123;

我的代码不知道的是我的验证失败，所以我根本没有改变名字属性！

编辑：

您还可以简化验证方法：

public static bool validateName(String name)
{
    Regex regex = new Regex("^[A-Z]");
    return regex.IsMatch(name)
}

Answer 4

我同意你的导师。

通常，您应该在“接受”之前在任何可以设置值的位置验证值。一般规则是，尝试设置值的任何方法在尝试设置时都应立即收到反馈。

对于您的示例，我将验证器放在您的FName公共属性的setter中，如果您的构造函数也接受FName值，那么只需在构造函数中调用FName setter以完全封装属性的行为，无论是验证行为还是该属性实现的任何其他业务规则：

public class User
{
    public User(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }

    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            if (!IsValid(value))
                // throw / handle appropriately
            else
                _firstName = value;
        }
    }
}

另外：远离缩写！不要使用FName;使用FirstName。

Answer 5

构造函数的目的是为类型的成员赋值。按照惯例，验证不是构造函数的责任验证任何信息取决于您正在构建的应用程序的业务。如果要创建一个模块化应用程序，其中每个组件都是出于特定目的，最好创建一个单独的类或一组类（取决于应用程序的大小）来执行所有业务验证。必须根据对一段数据施加的验证规则来调用此类验证。

验证构造函数中的信息

5 个答案: