从函数返回数据的最佳实践是什么?是返回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的用户信息。我认为在这种情况下抛出异常是不合适的??另外，我的印象是异常处理会损害性能。
当前回答
我是一名法国IT专业的学生，所以请原谅我的英语不好。在我们的类中，我们被告知这样的方法永远不应该返回null，也不应该返回空对象。这种方法的用户应该在尝试获取对象之前首先检查他正在寻找的对象是否存在。
使用Java，我们被要求添加一个断言exists(object):“您不应该尝试访问一个不存在的对象”;在任何可能返回null的方法的开头，以表达“先决条件”(我不知道英文单词是什么)。
在我看来，这真的不容易使用，但这就是我正在使用的，等待更好的东西。
其他回答
这取决于什么对你的案子最有意义。
返回null是否有意义?“不存在这样的用户”?
或者创建一个默认用户有意义吗?当您可以安全地假设如果用户不存在，则调用代码在请求时希望用户存在时，这是最有意义的。
或者，如果调用代码要求使用无效ID的用户，抛出异常(如“FileNotFound”)是否有意义?
然而，从分离关注点/SRP的角度来看，前两点更为正确。从技术上讲，第一个是最正确的(但只差一点点)——GetUserById应该只负责一件事——获取用户。通过返回其他内容来处理自己的“用户不存在”情况可能违反SRP。如果您确实选择抛出异常，则分隔为不同的check - bool DoesUserExist(id)是合适的。
根据下面大量的评论:如果这是一个api级别的设计问题，这个方法可以类似于“OpenFile”或“readwholfile”。我们正在从某个存储库中“打开”一个用户，并从结果数据中补充对象。在这种情况下，一个例外可能是合适的。也许不是，但也有可能。
所有的方法都是可以接受的——这取决于API/应用程序的上下文。
如果您打算表示没有可用的数据，返回null通常是最好的主意。
空对象表示已返回数据，而返回null则明确表示没有返回任何数据。
此外，如果试图访问对象中的成员，返回null将导致null异常，这对于突出显示有bug的代码很有用——试图访问没有任何成员的成员是没有意义的。访问空对象的成员不会失败，这意味着bug不会被发现。
我同意这里的大多数帖子，它们趋向于零。
我的理由是，生成一个具有非空属性的空对象可能会导致错误。例如，具有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.
我个人返回该对象的默认实例。原因是我希望该方法返回0到多或0到1(取决于该方法的目的)。使用这种方法，它将是任何类型的错误状态的唯一原因是，如果方法不返回任何对象，并且总是期望返回(就一对多或单数返回而言)。
至于假设这是一个业务领域的问题——我只是没有从等式的那一边看到它。返回类型的规范化是一个有效的应用程序体系结构问题。至少，它是编码实践标准化的主题。我怀疑是否有业务用户会说“在场景X中，只给他们一个null”。
我是一名法国IT专业的学生，所以请原谅我的英语不好。在我们的类中，我们被告知这样的方法永远不应该返回null，也不应该返回空对象。这种方法的用户应该在尝试获取对象之前首先检查他正在寻找的对象是否存在。
使用Java，我们被要求添加一个断言exists(object):“您不应该尝试访问一个不存在的对象”;在任何可能返回null的方法的开头，以表达“先决条件”(我不知道英文单词是什么)。
在我看来，这真的不容易使用，但这就是我正在使用的，等待更好的东西。
