Entity Framework 和 ORM 的新手，但是可能有一个独特的情况，我们正在考虑对我们的应用程序的工作方式进行一些重构。
现在我们正在使用内存中的分布式缓存架构，基本上作为内存中数据库以一种相当低效且容易出错的方式使用，从而与持久数据同步，甚至缓存中的对象也不一致。
我们的想法是回到核心并集成某种形式的 ORM(如 Entity Framework )或在 SQL 中手动创建存储过程以引入创建复杂类所需的数据。
举个例子，假设我们有一个 SomeDashboard 类，它将具有许多根据请求的 Dashboard 设置的属性(存储在 SQL 中)，但是许多与 Dashboard 相关的对象列表，例如 Products 或 Reviews 等。可以编写一个存储过程来利用单个数据库请求将拉回多个结果集以创建所有这些列表和对象值。
是创建存储过程来执行此操作更好，还是创建多个存储过程以分段获取数据(意味着更多的 SQL 调用)，或者借助 Entity Framework 对所有数据进行分段？对象在一起？
一些东西会变得不稳定，导致它需要经常重建；担心每次我们构建对象时都会有如此多的连接和如此多的请求来扩展数据库。
也许这足以给出某种形式的方向；我知道它充其量是模糊的。
与 Entity Framework 相关的问题的另一部分是——将所有内容映射到现有数据库和类有多难？
从高层次上看……感觉内存分布式缓存的集成没有经过深思熟虑，并且以“抢先优化”的方式完成，导致问题多于解决问题；所以回到根源并大量使用 SQL，然后在可能需要的地方有选择地集成缓存，当 SQL 的性能成为问题时，这似乎是最好的主意。
最佳答案
关于你问题的第一部分，你应该在 Entity Framework 上使用 eager loading 并让它为你查询数据。这是使用 OR/M 的目的:您专注于应用程序代码，而 OR/M 负责读取和写入数据到 SQL 数据源的原始部分。
查看这篇 MSDN 文章:Loading Related Entities .
关于...
The other part of the question related to Entity Framework, would be -- how hard is it to map everything to existing databases and classes
这个没有确定的答案。这可能取决于您的数据库设计。如果您的数据库是使用良好的关系设计实践构建的，通常 OR/M 会更容易针对该数据库进行配置。
关于c# - 具有现有数据库和具有多个源的类的 Entity Framework 与手动存储过程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36110602/