为什么C#属性getter不能从数据库中读取？这个问题的一些答案和评论：SimplestC#codetopollaproperty?，这意味着在属性的getter中从数据库中检索数据通常不是一个好主意。为什么这么糟糕？（如果您有自己的信息来源，请提及。）如果这会影响您的回答，我通常会在第一次“获取”后将信息存储在变量中以供重用。因为从数据库中检索数据可能会导致任意数量的异常，而属性获取器通常不应抛出异常。属性获取器的预期行为只是返回一个值；如果它实际上做的远不止于此，那么它应该是一种方法。我知道微软的一些文档提供了没有更详细地抛出异常的原因，但我找不到它。如果我这样做，我将用指向它的链接替换它。这可能是它，但我不确定：http://msdn.microsoft.com/en-us/library/bzwdh01d%28VS.71%29.aspx#cpconpropertyusageguidelinesanchor1这很糟糕，因为（除其他外）它违反了最小惊奇原则。程序员通常希望属性进行简单的获取/设置。将数据访问封装在属性中可能会导致异常、产生副作用并改变数据库中数据的状态，这通常是不希望发生的。我并不是说没有复杂属性的情况——有时，它可能是一个很好的解决方案。但是，这不是预期的做事方式。简短版本：让财产收购方直接访问数据库会违反关注点分离原则。更多详细信息：通常，属性旨在表示与对象关联的数据，例如Person对象的FirstName属性。属性值可以在内部或外部设置，但是在对象上修改和检索此数据的行为应该与检索数据或将数据提交到持久存储的行为分开。每次访问getter时，都会对数据库进行另一次调用。根据定义，getter应该只是封装数据，而不是函数。此外，如果您有多个getter需要进出数据库，您可能会重新定义该函数并多次访问数据库。为什么不在一个集中的地方处理它，而不是将它分散到多个属性中呢？方法用于类级别的数据修改和功能，属性仅用于单个数据修改和检索。除了可能的例外，查询数据库是一种惰性操作。在这两个方面，使用属性获取器作为数据库访问器都违反了对客户端代码的最小意外原则。如果我看到一个带有属性的库类，我不希望它做很多工作，而是访问一个容易检索的值。这里最不令人惊奇的选项是提供一个老式的、简单的Get函数。如果您真的只是从数据库中检索值而不是将其写回（如只读属性），那么本质上并没有错。特别是如果没有父母就不能存在该财产。但在实现中它可能会导致可维护性问题。您正在通过访问信息来检索存储的信息。如果您继续将此模式用于其他属性，并且存储系统的各个方面发生变化，则这些变化可能会扩散到整个代码库。例如，表名或列数据类型更改。这就是为什么在属性getter中进行数据库调用是不好的。请注意：如果数据库在您尝试检索值时抛出异常，那么您的代码（或调用客户端代码）中显然存在错误，无论您将数据访问代码放在何处，异常仍会发生。很多时候数据由类中的某种集合支持，可能会抛出异常，并且以这种方式存储属性值是标准做法（请参阅EventHandlerList）。属性是专门设计的，因为程序员在获取和设置值时需要执行额外的逻辑，例如验证。说完所有这些，重新审视您的代码并问问自己“以后更改有多容易？”从那里你应该从一个更易于维护的解决方案开始。以上是C#学习教程：WhynotreadtheC#propertygetterfromtheDB?如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
