具有现有数据库和具有多个源的类的实体框架与手动存储过程

Question

Entity Framework 和 ORM 的新手，但可能有一个独特的情况，我们正在考虑重构我们的应用程序的工作方式。

现在我们正在使用内存中分布式缓存架构，基本上作为内存数据库，效率相当低且容易出错，因此与持久数据的同步，甚至缓存中的对象都不一致。

我们的想法是回到核心，要么集成某种形式的 ORM，如实体框架，要么在 SQL 中手动创建存储过程，以引入创建复杂类所需的数据。

例如，假设我们有一个 SomeDashboard 类，它将具有许多基于请求的 Dashboard 设置的属性（存储在 SQL 中），但随后有许多与 @ 相关的对象列表987654323@，例如Products 或Reviews 等。可以编写一个存储过程，该过程将利用单个数据库请求，该请求将拉回多个结果集以创建所有这些列表和对象值。

最好是创建存储过程来执行此操作，还是创建多个存储过程来分段获取数据（意味着更多的 SQL 调用），或者搭载 Entity Framework 来对所有对象在一起？

一些不稳定的东西，导致需要经常重建；每次我们构建对象时，担心数据库的扩展需要如此多的连接和如此多的请求。

也许这足以给出某种形式的方向；我知道它充其量是模糊的。

与实体框架相关的问题的另一部分是——将所有内容映射到现有数据库和类有多难？

从高层次上看……感觉内存分布式缓存的集成并没有经过深思熟虑，并且以“抢先优化”的方式完成，导致问题多于解决；所以回到根源并大量使用 SQL，然后在可能需要的地方有选择地集成缓存，当 SQL 的性能成为问题时似乎是最好的主意。

Answer 1

关于你问题的第一部分，你应该在实体框架上使用eager loading，让它为你查询数据。这是使用 OR/M 的目的：您专注于应用程序代码，而 OR/M 负责读取和写入数据到 SQL 数据源的原始部分。

查看这篇 MSDN 文章：Loading Related Entities。

关于...

与实体框架相关的问题的另一部分是 -- 将所有内容映射到现有数据库和类有多难

这没有确定的答案。这可能取决于您的数据库设计。如果您的数据库是使用良好的关系设计实践构建的，那么通常针对该数据库配置 OR/M 会更容易。