从函数返回数据的最佳实践是什么?是返回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，因为这是我所期望的DAL/Repository层的操作方式。
如果它不存在，不要返回任何可以被解释为成功获取对象的东西，null在这里工作得很好。
最重要的是在你的DAL/Repos层保持一致，这样你就不会对如何使用它感到困惑。
异步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));
}
}
我个人返回该对象的默认实例。原因是我希望该方法返回0到多或0到1(取决于该方法的目的)。使用这种方法，它将是任何类型的错误状态的唯一原因是，如果方法不返回任何对象，并且总是期望返回(就一对多或单数返回而言)。
至于假设这是一个业务领域的问题——我只是没有从等式的那一边看到它。返回类型的规范化是一个有效的应用程序体系结构问题。至少，它是编码实践标准化的主题。我怀疑是否有业务用户会说“在场景X中，只给他们一个null”。
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”之类的额外方法来首先检查是否存在这样的用户。异常的性能绝对不是完全不使用它们的理由，除非您有真正的性能问题。
更多的肉要磨:让我们说我的DAL返回一个NULL的GetPersonByID，正如一些建议。我的(相当薄)BLL应该做什么，如果它收到一个NULL?传递NULL，并让最终消费者担心它(在这种情况下，一个ASP。网络页面)?让BLL抛出一个异常怎么样?
BLL可能正在被ASP使用。Net和Win App，或者其他类库——我认为期望最终消费者本质上“知道”GetPersonByID方法返回null是不公平的(除非使用空类型，我猜)。
My take (for what it's worth) is that my DAL returns NULL if nothing is found. FOR SOME OBJECTS, that's ok - it could be a 0:many list of things, so not having any things is fine (e.g. a list of favourite books). In this case, my BLL returns an empty list. For most single entity things (e.g. user, account, invoice) if I don't have one, then that's definitely a problem and a throw a costly exception. However, seeing as retrieving a user by a unique identifier that's been previously given by the application should always return a user, the exception is a "proper" exception, as in it's exceptional. The end consumer of the BLL (ASP.Net, f'rinstance) only ever expects things to be hunky-dory, so an Unhandled Exception Handler will be used instead of wrapping every single call to GetPersonByID in a try - catch block.
如果我的方法有明显的问题，请让我知道，因为我总是渴望学习。正如其他帖子所说，异常是代价高昂的事情，“先检查”的方法是好的，但异常应该只是例外。
我很喜欢这篇文章，很多关于“视情况而定”的好建议:-)
