如何在c#中使用lambda表达式检测元素是否存在

本文关键字：检测 表达式 元素 是否 存在 lambda | 更新日期: 2023-09-27 18:10:28

我一直在使用try/catch语句来运行当我解析它时元素是否存在。显然这不是最好的方法。我一直在使用LINQ (lambda表达式)进行大部分解析，但我只是不知道如何检测元素是否存在。

我发现一些解决方案的一个大问题是，它们比使用try/catch块多花3-4倍的代码，这有点违背了目的。

我假设代码看起来像这样:

if(document.Element("myElement").Exists())
{
   var myValue = document.Element("myElement").Value;
}

我确实找到了这个链接，但在我的情况下，循环是不必要的，因为我可以保证，如果它存在，它只会出现一次。加上必须创建一个虚拟元素的事实，这似乎也没有必要。这似乎不是检查的最佳方法(或好方法)。什么好主意吗?

如何在c#中使用lambda表达式检测元素是否存在

XElement e = document.Element("myElement");
if (e != null)
{
    var myValue = e.Value; 
}
http://msdn.microsoft.com/en-us/library/system.xml.linq.xcontainer.element.aspx

"获取具有指定XName的第一个子元素(按文档顺序)。"

"如果没有指定名称的元素，则返回none。"

Any()是Linq命令

Assert.IsFalse( new [] { 1, 2, 3, 4 }.Any( i => i == 5 ));

顺便说一句，上面关于"try/catch" 的评论可能是正确的，但并非在几乎所有情况下都是正确的。这取决于您如何构建解决方案。在你的发布版本中，尽可能关闭那些闻起来像"调试"的标志，即使从远处看也是如此。运行时在构建过程中被告知记住堆栈跟踪和其他东西的次数越少，"try/catch"就会变得越快。

顺便说一句，#2:著名的建筑模式"告诉，不要问!"(TDA)和"开闭原则"(OCP) 禁止使用像"if (!(fp = fopen(…))"。他们不只是鼓励你使用"试/接"，而是强迫你这么做。因为OCP不仅要求在你自己的代码中遵守，而且在调用外部东西(即像stdio这样的库)时也要遵守。

为什么最后一句是OCP，而不是TDA ?因为你不允许扩大现有代码的含义。坚持简单的"fopen"示例，当结果为0时，您将怎么办?"fopen"到底为什么会失败?您可以检查是否有足够的空闲空间，或者文件系统是否可写。文件名是否有效。或者诸如此类的。但是，您的目标无法实现:打开文件。想象一个无头的应用程序，因此不可能有用户的干预。现在怎么办呢?完全没有理由进一步摸索这些东西，因为"fopen"失败了。你需要一个退路策略。点。如果"fopen"失败了，那它就失败了。

经验法则:认为你的代码总是成功的(KIS)。如果你的代码可能会因为结果集可能包含元素或不包含元素而"失败"，那么将逻辑放入类中。也许您必须跨不同的类(TDA)分发数据、属性、问题和方法。也许你必须根据SLA重新调整你的代码。 但是，在您的示例中，请确保元素存在。如果你不能，那不是你的错。在你的代码深处(一个包装器，所有以前的程序员的错误都被美化了)，把需要的数据转换成另一个实体，这样在上面就不需要"if"了。

Any()是检查元素是否存在的最简单的方法。

如果您必须确保元素是唯一的，则必须执行.Count() == 1之类的操作。或者，您可以实现自己的扩展方法，但这将只是围绕.Count == 1的包装。

相关文章：