在我们的业务对象中，我们有两个主要的Get方法:

为了让事情在语境中变得简单，或者你的问题是:

// Returns null if user does not exist
public UserEntity GetUserById(Guid userId)
{
}

// Returns a New User if user does not exist
public UserEntity GetNewOrExistingUserById(Guid userId)
{
}

第一种方法用于获取特定的实体，第二种方法用于在网页上添加或编辑实体。

这使我们能够在使用它们的上下文中两全其美。

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

我的理由是，生成一个具有非空属性的空对象可能会导致错误。例如，具有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.

我不喜欢从任何方法返回null，而是使用Option函数类型。不返回结果的方法返回空选项，而不是null。

而且，不能返回结果的方法应该通过名称来指明。我通常把Try或TryGet或TryFind放在方法名称的开头，以表明它可能返回一个空结果(例如TryFindCustomer, TryLoadFile等)。

这让调用者可以对结果应用不同的技术，比如收集管道(参见Martin Fowler的收集管道)。

下面是另一个使用返回Option而不是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;
}

(仅)在特定契约被破坏时抛出异常。 在您的特定示例中，请求基于已知Id的UserEntity，这将取决于丢失(删除)用户是否是预期情况。如果是，则返回null，但如果不是预期的情况，则抛出异常。 注意，如果函数名为UserEntity GetUserByName(字符串名)，它可能不会抛出而是返回null。在这两种情况下，返回空的UserEntity都没有帮助。

对于字符串、数组和集合，情况通常是不同的。我记得MS的一些指导原则，方法应该接受null作为一个“空”列表，但返回零长度的集合而不是null。字符串也是一样。注意，你可以声明空数组:int[] arr = new int[0];

我倾向于

如果对象id不存在，在不知道它是否应该存在时返回null。 当对象id应该存在时，如果对象id不存在则抛出。

我用这三种类型的方法来区分这两种场景。 第一:

Boolean TryGetSomeObjectById(Int32 id, out SomeObject o)
{
    if (InternalIdExists(id))
    {
        o = InternalGetSomeObject(id);

        return true;
    }
    else
    {
        return false;
    }
}

第二:

SomeObject FindSomeObjectById(Int32 id)
{
    SomeObject o;

    return TryGetObjectById(id, out o) ? o : null;
}

第三:

SomeObject GetSomeObjectById(Int32 id)
{
    SomeObject o;

    if (!TryGetObjectById(id, out o))
    {
        throw new SomeAppropriateException();
    }

    return o;
}