我正在编写一个Silverlight应用程序来处理数百万条记录。由于服务器上的负载可能非常重，因此我打算将一些处理转移到客户端。例如，如果我需要显示关于一本书及其作者的完整信息，我将希望使用AuthorID作为公共键连接book表和author表。与在服务器端执行JOIN不同，我将分别检索Author表和Book表，并使用c#代码在客户端连接它们，并将它们显示在DataGrid中。
客户端处于受控环境中，因此对其性能有最低限度的保证。因为有这么多的记录，因为没有更新发生在客户端datagrid，我会选择Raw SQL实体框架。但是，在执行客户端连接时存在一个问题。我的问题是，实体框架是否有助于使客户端连接更容易?考虑开发时间在这里不是一个重要的因素。
我的问题是，实体框架将有助于使客户端连接容易吗?
这是谁开发应用程序的问题。使用实体框架肯定有它的优点。它使开发人员能够在c#或其他。net环境中编写类似于T-SQL的语法，但它具有通过。net中已经存在的SQL库执行SQL的相同效率。
那么容易呢?也许吧。更有效率呢?我很怀疑。通常，您希望在服务器端存储过程中执行join之类的操作，只是因为数据库通常存储在不同的机器上，那么为什么要让一台机器为网站提供服务并进行所需的数据操作呢?
这是我对整个事情的看法。我知道有些人开始认为不需要编写存储过程，因为在。net中一切都变得如此容易，但我仍然喜欢它们。
我个人同意你在这种情况下使用原始SQL的选择，至少基于我在你的帖子中读到的。你需要尽可能"快速"地访问，而快速是性能目标，这与你的应用非常相关。所以你可以在你想要的地方调整你想要的。
我说的甚至是客户端，你想要做连接，考虑到你写的:"开发时间在这里不是一个重要因素"。
所以我个人支持Raw SQL。
问候。
数据库是专门为处理大量数据而设计的。服务器旨在处理此类场景。向客户端发送如此多的数据很容易严重影响性能。最好先在服务器端过滤数据，然后再发送给客户端。服务器就是为这个目的而设计的。
至于原始SQL与实体框架——如果你选择过滤服务器中的数据，你需要做特殊的优化——使用原始SQL，因为它的限制要少得多。否则，使用实体框架
我不知道实体框架与原始SQL，但你是否考虑过使用微软的缓存应用程序块与后备存储缓存?
这将在本地缓存数据-这听起来有点像你所追求的