我遵循“不要过早优化”的原则，并使用实体框架编写了我的 WCF 服务。
但是，我分析了性能，发现实体框架太慢了。 （我的应用程序在大约 1.2 秒内处理 2 条消息，而我正在重写的（旧版）应用程序同时处理 5-6 条消息。（旧版应用程序调用 sprocs 来进行数据库访问。）
我的分析表明实体框架占用了每条消息的大部分时间。
那么，我有什么选择呢？
有更好的 ORM 吗？（只支持对象的正常读写并且速度很快的东西..）
有没有办法让实体框架更快？ (Note：当我说更快时，我的意思是从长远来看，而不是第一次通话。 （第一个调用很慢（一条消息需要 15 秒），但这不是问题。我只需要它能够快速处理其余的消息。）
一些神秘的第三个选项将帮助我提高服务速度。
NOTE:我的大多数数据库交互都是创建和更新。我很少做选择和删除。
事实是，诸如实体框架之类的产品总是缓慢且低效，因为它们正在执行更多的代码。
我还发现人们建议应该优化 LINQ 查询、查看生成的 SQL、使用调试器、预编译、采取许多额外步骤等，即浪费大量时间，这很愚蠢。没有人说——简化！每个人都想通过采取更多步骤来使事情变得更加复杂（浪费时间）。
常识性的做法是根本不使用 EF 或 LINQ。使用简单的 SQL。没有什么问题。仅仅因为程序员中有从众心理，他们有使用每一个新产品的冲动，并不意味着它是好的或会起作用。大多数程序员认为，如果他们合并大公司发布的每一段新代码，就会使他们成为更聪明的程序员；根本不是真的。智能编程主要是关于如何在最短的时间内以更少的麻烦、不确定性做更多的事情。记住——时间！这是最重要的元素，因此请尝试找到方法，不要将其浪费在解决仅仅为了符合某些奇怪的所谓“模式”而编写的糟糕/臃肿代码中的问题上。
放松，享受生活，从编码中休息一下，停止使用额外的功能、代码、产品、“模式”。生命短暂，代码的生命更短，这当然不是火箭科学。删除 LINQ、EF 等层，您的代码将高效运行、可扩展，而且，它仍然易于维护。太多的抽象是一种不好的“模式”。
这就是您问题的解决方案。
