从函数返回数据的最佳实践是什么?是返回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的用户信息。我认为在这种情况下抛出异常是不合适的??另外，我的印象是异常处理会损害性能。
当前回答
在我们的业务对象中，我们有两个主要的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将是可接受的，因为这是数据访问逻辑。
另一方面，如果我希望我的参数反映一个主键，我应该只返回一行，如果我返回了不止一行，我就会抛出异常。0可以返回null, 2则不行。
现在，如果我有一些登录代码检查LDAP提供程序，然后检查DB以获得更多详细信息，并且我希望它们始终保持同步，那么我可能会抛出异常。正如其他人所说，这是商业规则。
Now I'll say that is a general rule. There are times where you may want to break that. However, my experience and experiments with C# (lots of that) and Java(a bit of that) has taught me that it is much more expensive performance wise to deal with exceptions than to handle predictable issues via conditional logic. I'm talking to the tune of 2 or 3 orders of magnitude more expensive in some cases. So, if it's possible your code could end up in a loop, then I would advise returning null and testing for it.
更多的肉要磨:让我们说我的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.
如果我的方法有明显的问题，请让我知道，因为我总是渴望学习。正如其他帖子所说，异常是代价高昂的事情，“先检查”的方法是好的，但异常应该只是例外。
我很喜欢这篇文章，很多关于“视情况而定”的好建议:-)
这取决于什么对你的案子最有意义。
返回null是否有意义?“不存在这样的用户”?
或者创建一个默认用户有意义吗?当您可以安全地假设如果用户不存在，则调用代码在请求时希望用户存在时，这是最有意义的。
或者，如果调用代码要求使用无效ID的用户，抛出异常(如“FileNotFound”)是否有意义?
然而，从分离关注点/SRP的角度来看，前两点更为正确。从技术上讲，第一个是最正确的(但只差一点点)——GetUserById应该只负责一件事——获取用户。通过返回其他内容来处理自己的“用户不存在”情况可能违反SRP。如果您确实选择抛出异常，则分隔为不同的check - bool DoesUserExist(id)是合适的。
根据下面大量的评论:如果这是一个api级别的设计问题，这个方法可以类似于“OpenFile”或“readwholfile”。我们正在从某个存储库中“打开”一个用户，并从结果数据中补充对象。在这种情况下，一个例外可能是合适的。也许不是，但也有可能。
所有的方法都是可以接受的——这取决于API/应用程序的上下文。
我会说返回null而不是空对象。
但你在这里提到的具体例子， 您正在通过用户id搜索用户，即排序 那个用户的键，在这种情况下，我可能想要 如果没有用户实例，则抛出异常 发现。
这是我通常遵循的规则:
如果通过主键查找操作没有找到结果， 把ObjectNotFoundException。 如按任何其他标准没有发现结果， 返回null。 如果通过非关键条件查找未找到结果，则可能返回多个对象 返回一个空集合。
我通常返回null。它提供了一种快速而简单的机制来检测是否出现了错误，而不会抛出异常，也不会到处使用大量的try/catch。
