undefined此外，次优的LINQ查询可能导致的性能问题远远超过避免公开IQueryables或通过系统地过滤任何数据访问逻辑所需的记录数。实际上不做任何事情的抽象级别（第一个可能更重要）。通常，这不会成为问题，因为大多数领先的LINQ提供程序会在翻译过程中优化您的查询逻辑。如果您想从前端隐藏查询逻辑，请不要尝试创建通用存储库。使用实际的特定于业务的方法封装查询。现在，我可能错了，但我假设您对存储库模式的使用是受领域驱动设计的启发。如果是这种情况，那么使用存储库的原因是允许您创建一个主要与域模型有关的持久性不可知域。但是，除了将语义从创建读取更新删除更改为查找添加删除保存之外，使用这样的通用存储库并没有多大帮助。那里没有任何真正的商业知识。考虑interfaceIPersonRepository{PersonGetById(intid);的重要性（和可用性）IEnumerableFindByName（字符串名字，字符串姓氏）；}而不是interfaceIRepository{IEnumerableFindBy(Queryquery);此外，您真的可以指出使用IRepository（而不是IQueryable）的好处吗？另外，请考虑使用通用方法，您根本没有真正封装查询逻辑。您最终将在外部构建它，这将导致更多不必要的代码。*关于使用IQueryable建议的资源的另一个注意事项是，值得检查它们的发布日期。曾经有一段时间，LINQ提供程序的可用性非常有限（早期的EF和LINQ-to-SQL）。那时公开IQueryable会导致与一些更流行的MicrosoftORM替代品不兼容（LINQ-to-NHibernate早已实现它）。此时此刻，LINQ支持在严肃的ORM.NET库中几乎无处不在。与上面的主导答案相反，明确的反对意见是单元测试。返回一个简单的genericsIQueryable对于任何有权调用它的客户端来说都是一个有漏洞的抽象。因此，对存储库方法没有限制，单元测试中也没有断言。IQueryable的使用几乎肯定取决于应用程序本身的上下文和体系结构。例如，如果你自己在做一个个人项目，你可以安全地承担使用这种不受约束的权力的责任，而不会诅咒除了你自己之外的任何人。但是，如果您正在为一家代码投入生产的公司开发应用程序，那么肯定会有比您更多的利益相关者。在这种情况下，您可能在数据访问层工作，并试图让其他开发人员使用您的代码。现在您需要控制进出的内容，这样它们就不会破坏您的代码，您也不会破坏它们。这是激励，单元测试是执行。话虽如此，但不要简单地使用IQueryable。使用对您的应用程序有意义的内容。以上就是C#学习教程的全部内容：Repository/IQueryable/查询对象分享。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
