Entity Framework 和 ORM 的新手，但是可能有一个独特的情况，我们正在考虑在某种程度上重构我们的应用程序的工作方式。
现在我们正在使用内存分布式缓存架构，基本上作为内存数据库，效率相当低且容易出错，因此与持久数据的同步，甚至缓存中的对象都不一致。
这个想法是有点回到核心，要么集成某种形式的 ORM，比如实体框架，要么在 SQL 中手动创建存储过程，以引入创建复杂类所需的数据。
举个例子，假设我们有一个类SomeDashboard，它将有许多基于Dashboard请求设置的属性（存储在 SQL 中），但随后有许多与 相关的对象列表Dashboard，例如ProductsorReviews等。可以写一个存储过程，它将利用单个数据库请求，该请求将拉回多个结果集以创建所有这些列表和对象值。
创建存储过程来做到这一点会更好，还是创建多个存储过程来获取数据（意味着更多的 SQL 调用），或者捎带实体框架来将所有对象拼凑在一起会更好吗？
一些不稳定的东西，导致需要经常重建；每次我们构建对象时，担心使用如此多的连接和如此多的请求来扩展数据库。
也许这足以给出某种形式的方向。我知道这充其量是模糊的。
与实体框架相关的问题的另一部分是——将所有内容映射到现有数据库和类有多难？
从高层次上看……感觉内存分布式缓存的集成没有很好地考虑，并且以“抢先优化”的方式完成，它导致的问题多于解决问题；所以回到根源并大量使用 SQL，然后在可能需要的地方有选择地集成缓存，当 SQL 的性能成为问题时似乎是最好的主意。