从函数返回数据的最佳实践是什么?是返回Null对象好还是返回空对象好?为什么要选择一种而不是另一种呢?
考虑一下:
public UserEntity GetUserById(Guid userId)
{
//Imagine some code here to access database.....
//Check if data was returned and return a null if none found
if (!DataExists)
return null;
//Should I be doing this here instead?
//return new UserEntity();
else
return existingUserEntity;
}
让我们假设在这个程序中存在有效的情况，即数据库中没有具有该GUID的用户信息。我认为在这种情况下抛出异常是不合适的??另外，我的印象是异常处理会损害性能。
当前回答
如果您打算表示没有可用的数据，返回null通常是最好的主意。
空对象表示已返回数据，而返回null则明确表示没有返回任何数据。
此外，如果试图访问对象中的成员，返回null将导致null异常，这对于突出显示有bug的代码很有用——试图访问没有任何成员的成员是没有意义的。访问空对象的成员不会失败，这意味着bug不会被发现。
其他回答
异步TryGet模式:
对于同步方法，我相信@Johann Gerell的回答是适用于所有情况的模式。
但是带有out参数的TryGet模式不适用于Async方法。
使用c# 7的元组文字，你现在可以这样做:
async Task<(bool success, SomeObject o)> TryGetSomeObjectByIdAsync(Int32 id)
{
if (InternalIdExists(id))
{
o = await InternalGetSomeObjectAsync(id);
return (true, o);
}
else
{
return (false, default(SomeObject));
}
}
在我们的业务对象中，我们有两个主要的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)
{
}
第一种方法用于获取特定的实体，第二种方法用于在网页上添加或编辑实体。
这使我们能够在使用它们的上下文中两全其美。
我个人会返回null，因为这是我所期望的DAL/Repository层的操作方式。
如果它不存在，不要返回任何可以被解释为成功获取对象的东西，null在这里工作得很好。
最重要的是在你的DAL/Repos层保持一致，这样你就不会对如何使用它感到困惑。
You should be throwing an exception if it is an exceptional circumstance that you call that code with an invalid user ID. If it is NOT an exceptional circumstance, then what you are essentially doing is using a "getter" method to test whether a user exists or not. That is like trying to open a file to see if it exists or not (lets stick to c#/java here) instead of using the exists method, or trying to access dictionary elements and seeing if they exist by looking at the return value instead of using the "contains" method first.
因此，您很可能会使用诸如“exists”之类的额外方法来首先检查是否存在这样的用户。异常的性能绝对不是完全不使用它们的理由，除非您有真正的性能问题。
这取决于什么对你的案子最有意义。
返回null是否有意义?“不存在这样的用户”?
或者创建一个默认用户有意义吗?当您可以安全地假设如果用户不存在，则调用代码在请求时希望用户存在时，这是最有意义的。
或者，如果调用代码要求使用无效ID的用户，抛出异常(如“FileNotFound”)是否有意义?
然而，从分离关注点/SRP的角度来看，前两点更为正确。从技术上讲，第一个是最正确的(但只差一点点)——GetUserById应该只负责一件事——获取用户。通过返回其他内容来处理自己的“用户不存在”情况可能违反SRP。如果您确实选择抛出异常，则分隔为不同的check - bool DoesUserExist(id)是合适的。
根据下面大量的评论:如果这是一个api级别的设计问题，这个方法可以类似于“OpenFile”或“readwholfile”。我们正在从某个存储库中“打开”一个用户，并从结果数据中补充对象。在这种情况下，一个例外可能是合适的。也许不是，但也有可能。
所有的方法都是可以接受的——这取决于API/应用程序的上下文。
