我会说返回null而不是空对象。

但你在这里提到的具体例子， 您正在通过用户id搜索用户，即排序 那个用户的键，在这种情况下，我可能想要 如果没有用户实例，则抛出异常 发现。

这是我通常遵循的规则:

如果通过主键查找操作没有找到结果， 把ObjectNotFoundException。 如按任何其他标准没有发现结果， 返回null。 如果通过非关键条件查找未找到结果，则可能返回多个对象 返回一个空集合。

如果返回的对象是可以迭代的对象，我将返回一个空对象，这样我就不必首先测试null。

例子:

bool IsAdministrator(User user)
{
    var groupsOfUser = GetGroupsOfUser(user);

    // This foreach would cause a run time exception if groupsOfUser is null.
    foreach (var groupOfUser in groupsOfUser) 
    {
        if (groupOfUser.Name == "Administrators")
        {
            return true;
        }
    }

    return false;
}

我个人会返回null，因为这是我所期望的DAL/Repository层的操作方式。

如果它不存在，不要返回任何可以被解释为成功获取对象的东西，null在这里工作得很好。

最重要的是在你的DAL/Repos层保持一致，这样你就不会对如何使用它感到困惑。

对于集合类型，我将返回一个空集合，对于所有其他类型，我更喜欢使用NullObject模式来返回实现与返回类型相同接口的对象。有关该模式的详细信息，请查看链接文本

使用NullObject模式这将是:-

public UserEntity GetUserById(Guid userId)

｛ //假设这里有一些代码来访问数据库.....

 //Check if data was returned and return a null if none found
 if (!DataExists)
    return new NullUserEntity(); //Should I be doing this here instead? return new UserEntity();  
 else
    return existingUserEntity;

}

class NullUserEntity: IUserEntity { public string getFirstName(){ return ""; } ...} 

我同意这里的大多数帖子，它们趋向于零。

我的理由是，生成一个具有非空属性的空对象可能会导致错误。例如，具有int ID属性的实体的初始值为ID = 0，这是一个完全有效的值。如果这个对象，在某些情况下，被保存到数据库中，这将是一件坏事。

对于任何带有迭代器的东西，我总是使用空集合。类似的

foreach (var eachValue in collection ?? new List<Type>(0))

在我看来是代码的味道。集合属性永远不应该为空。

An edge case is String. Many people say, String.IsNullOrEmpty isn't really necessary, but you cannot always distinguish between an empty string and null. Furthermore, some database systems (Oracle) won't distinguish between them at all ('' gets stored as DBNULL), so you're forced to handle them equally. The reason for that is, most string values either come from user input or from external systems, while neither textboxes nor most exchange formats have different representations for '' and null. So even if the user wants to remove a value, he cannot do anything more than clearing the input control. Also the distinction of nullable and non-nullable nvarchar database fields is more than questionable, if your DBMS is not oracle - a mandatory field that allows '' is weird, your UI would never allow this, so your constraints do not map. So the answer here, in my opinion is, handle them equally, always.

Concerning your question regarding exceptions and performance: If you throw an exception which you cannot handle completely in your program logic, you have to abort, at some point, whatever your program is doing, and ask the user to redo whatever he just did. In that case, the performance penalty of a catch is really the least of your worries - having to ask the user is the elephant in the room (which means re-rendering the whole UI, or sending some HTML through the internet). So if you don't follow the anti-pattern of "Program Flow with Exceptions", don't bother, just throw one if it makes sense. Even in borderline cases, such as "Validation Exception", performance is really not an issue, since you have to ask the user again, in any case.

还有一种方法涉及传入一个回调对象或委托，它将对值进行操作。如果没有找到值，则不调用回调。

public void GetUserById(Guid id, UserCallback callback)
{
    // Lookup user
    if (userFound)
        callback(userEntity);  // or callback.Call(userEntity);
}

当您希望避免在整个代码中进行空检查时，以及当找不到值并不是错误时，这种方法非常有效。如果需要任何特殊处理，还可以在没有找到对象时提供回调。

public void GetUserById(Guid id, UserCallback callback, NotFoundCallback notFound)
{
    // Lookup user
    if (userFound)
        callback(userEntity);  // or callback.Call(userEntity);
    else
        notFound(); // or notFound.Call();
}

使用单个对象的相同方法如下所示:

public void GetUserById(Guid id, UserCallback callback)
{
    // Lookup user
    if (userFound)
        callback.Found(userEntity);
    else
        callback.NotFound();
}

从设计的角度来看，我真的很喜欢这种方法，但是它的缺点是在不支持第一类函数的语言中使调用站点变得更庞大。