Question

在此特定应用程序中，没有单独的数据层，数据访问代码位于实体本身。例如，考虑一个Customer实体，然后在Customer.cs文件中定义成员和属性，您有方法加载Customer对象，如下所示

public bool TryLoad(int customerID, out Customer customer)
{
    bool success = false
    try
    {
        //code which calls the db and fills a SqlDataReader
        ReadDataFromSqlDataReader(reader);
        success = true;
    }
    catch(Exception ex)  
    {
      LogError();
      success = false;
    }
    return success;
}

现在，在ReadDataFromSqlDataReader（reader）中，tryparse用于将数据从阅读器加载到对象中。例如

public void ReadDataFromSqlDataReader(reader)
{
   int.TryParse(reader["CustomerID"].ToString(), out this.CustomerID);
   PhoneNumber.TryParse(reader["PhoneNumber"].ToString(), out this.PhoneNumber);
   ... similar TryParse code for all the other fields..
}

使用TryParse读取读者的所有属性是一种好习惯吗？一个开发者告诉我，这样做是因为TryParse比int.Parse具有更好的性能。但是当你从db读取的值不符合你的代码期望时，你不希望抛出异常吗？我的意思是在这种情况下，如果数据库中的电话号码错误，那么可能根本不应该初始化该对象而不是加载具有空电话号码的对象？

Answer 1

是的，遵循 fail-fast 原则，您希望在值返回时无法转换为预期类型时抛出异常。

如果其中一个操作失败并且您继续好像没有发生任何事情，那么您可能会遇到难以捕捉并且很难确定的奇怪错误：当数据库应该更新现有行时，它们会被添加到数据库中，数据神秘地消失，狗和猫共同生活......你明白了。

另一方面，如果你立即抛出异常，你就会确切地知道你的问题在哪里，你可以抓住它并在它变得更糟之前修复它。

如果失败，

TryParse将比Parse更快地工作，因为它不必抛出异常（这可能很昂贵），但如果你假设事情会成功（这段代码通过不使用解析的结果来完成，你应该使用Parse获得相同的性能。

Answer 2

将数据插入数据库时执行有效验证。这不是一个好的设计，可以在数据库中输入错误的数据。如果数据库中包含错误的电话号码，则应要求用户再次输入电话号码（如果必须输入电话号码），如果电话号码不重要，则可以在数据不良的情况下将电话号码初始化为空。

Answer 3

我不会使用TryParse。如果我的数据库中有垃圾，我希望解决这个问题。如果数据在解析方面不明确（例如，Varchar带有int或double作为字符串）我想要整理我的架构，TryParse作为类型检测将是一个快速而简单的黑客。

Answer 4

在插入和/或更新数据时，您在做什么样的验证？

只要您在此处应用某种形式的验证，我个人就不会验证来自数据库的数据，因为您应该确信您只是在提供有效数据。

Answer 5

如果你要处理它，那么你应该抛出异常。但是，如果您不关心异常，并且如果您要过滤正确的数据并使用它（在本例中为非零），则可以跳过。

Answer 6

As，TryParse返回布尔值。因此，我可以基于ByPass/Continue值Upcoming Logic/Any Database Boolean请求{{1}}。我不会让这种情况发生异常。为此，我将进行记录等。

解析

引发异常。

如果您确定该值有效，请使用它

<强>的TryParse

返回表示是否成功的bool

它只是在内部尝试/捕获为什么没有例外实现，以便快速

如果值可能是InValid
，请使用它

如果来自db的数据不好，会抛出异常吗？

6 个答案: