从函数返回数据的最佳实践是什么?是返回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的用户信息。我认为在这种情况下抛出异常是不合适的??另外，我的印象是异常处理会损害性能。
当前回答
我们使用CSLA。NET，并且它认为失败的数据获取应该返回一个“空”对象。这实际上是相当烦人的，因为它要求检查obj。IsNew而不是obj == null。
正如前面提到的，null返回值将导致代码立即失败，从而降低了由空对象引起的隐形问题的可能性。
就我个人而言，我认为null更优雅。
这是一种非常常见的情况，我很惊讶这里的人似乎对此感到惊讶:在任何web应用程序中，数据通常是使用querystring参数获取的，这显然会被破坏，因此要求开发人员处理“未找到”的情况。
你可以这样处理:
if (User.Exists(id)) {
this.User = User.Fetch(id);
} else {
Response.Redirect("~/notfound.aspx");
}
.．.但是这每次都是对数据库的额外调用，这在高流量页面上可能是一个问题。而:
this.User = User.Fetch(id);
if (this.User == null) {
Response.Redirect("~/notfound.aspx");
}
.．.只需要一个呼叫。
其他回答
异步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));
}
}
还有一种方法涉及传入一个回调对象或委托，它将对值进行操作。如果没有找到值，则不调用回调。
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();
}
从设计的角度来看，我真的很喜欢这种方法，但是它的缺点是在不支持第一类函数的语言中使调用站点变得更庞大。
这是一个业务问题，取决于具有特定Guid Id的用户的存在是否是该函数的预期正常用例，还是会阻止应用程序成功完成该方法向用户对象提供的任何功能的异常情况……
如果它是一个“异常”，因为缺少具有该Id的用户将阻止应用程序成功完成它正在做的任何功能，(假设我们正在为我们已向其发货的客户创建发票……)，那么这种情况应该抛出ArgumentException(或其他一些自定义异常)。
如果没有用户(调用此函数的潜在正常结果之一)，则返回空值....
编辑:(处理亚当在另一个回答中的评论)
If the application contains multiple business processes, one or more of which require a User in order to complete successfully, and one or more of which can complete successfully without a user, then the exception should be thrown further up the call stack, closer to where the business processes which require a User are calling this thread of execution. Methods between this method and that point (where the exception is being thrown) should just communicate that no user exists (null, boolean, whatever - this is an implementation detail).
但是如果应用程序中的所有进程都需要一个用户，我仍然会在这个方法中抛出异常……
如果您打算表示没有可用的数据，返回null通常是最好的主意。
空对象表示已返回数据，而返回null则明确表示没有返回任何数据。
此外，如果试图访问对象中的成员，返回null将导致null异常，这对于突出显示有bug的代码很有用——试图访问没有任何成员的成员是没有意义的。访问空对象的成员不会失败，这意味着bug不会被发现。
更多的肉要磨:让我们说我的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.
如果我的方法有明显的问题，请让我知道，因为我总是渴望学习。正如其他帖子所说，异常是代价高昂的事情，“先检查”的方法是好的，但异常应该只是例外。
我很喜欢这篇文章，很多关于“视情况而定”的好建议:-)
