EF 4.1 N层ASP.Net混乱

我希望你能给我任何建议，我将不胜感激

我已经使用EF4.0一段时间了，现在使用以下对象上下文管理技术。我有一个相当简单的设置，一个web项目连接到一个BLL，一个DAL。web和BLL引用DAL实体对象。它一直运转良好，但似乎非常缓慢。它是一个ASP.NETWebForms应用程序，使用现有的数据库模型（即，不是先编码），并指向SQLServer2005DB

不管怎样，我现在重新审视架构，因为我们收到了关于屏幕对屏幕性能的投诉。我已经完成了大部分可能的UI增强，但我认为现在的问题是使用EF进行保存、重定向和加载

该网站是一系列汽车保险报价页面。我现在希望在会话中创建相关对象，即第1页创建quote对象，填充字段，第2页，添加X个其他驱动程序，第3页添加索赔/定罪，然后将对象保存到数据库。用户将能够在报价过程中的任何时候保存和退出，因此保存不会总是在最后。我们还需要能够加载第1页的信息，并在他们单击“下一步”时在内存中进行更新，最后在他们准备完成报价时更新数据库

目前，我们正在同一页面上进行检索和保存。您如何建议我们转到存储在会话中/最终提交

我已经浏览了各种msdn页面，对于这个相当简单的应用程序，我很难将它们全部整合到4.1的最新“最佳实践”中。我看过Julie Lerman的视频，但她的n'tier只做了一个简单的检索和“添加”，可疑地遗漏了更新部分，因为我怀疑这并不简单。你认为我应该使用自跟踪实体（我读到人们在这方面有很多问题，但他们的架构可能更复杂）还是其他一些方法来存储会话中的EF对象并进行更改

---

非常感谢您提供的任何帮助/想法。

在会话中存储数据可以有效地减少IO，但这不是一个简单的决定。您不应该将大量数据置于会话状态，而且我们无法从您的描述中分辨出您正在谈论的数据量，或者并发活动会话的数量

还有会话状态提供程序的问题。如果您使用的是单台服务器，可能会使用进程内会话状态，这很快，但是如果您有大量用户和大量数据，很快就会遇到内存压力问题

如果您使用的是web场，则必须使用共享会话状态，可能需要使用SQL Server会话状态提供程序，因此在每次交互时都会读取和写入数据库，这可能会更糟

但是，第一步是确保您了解问题所在。不要假设你的性能问题在哪里，试着重新设计它们。使用分析或检测技术来识别真正的瓶颈，并将精力集中在这些瓶颈上

---

你可能会对你的问题所在感到惊讶。这很可能只是一个数据库优化问题。

谢谢您的评论。我知道会话状态提供程序中的差异。我们目前正在SQLServer中存储数据，但最终会转移到AppFabric。我曾使用过Jetbrains dotrace和SQL profiler等工具，但我认为一定有更好的方法使用EF4.1实现n层ASP.net。有没有人有任何想法或实际可行的架构示例？Rick，这个问题太广泛了。有许多潜在的设计，您当前使用的设计与其他设计一样有效。我曾经研究过ASP.NET解决方案，这些解决方案使用DB持久化存储库和基于会话状态的存储库，在每种情况下都具有同样好的性能。事实上，我们刚刚修改了一个应用程序，让它走另一条路（从基于状态到数据库持久化）。一个未必天生比另一个好。你需要找到适合你的应用程序的东西，这取决于它的详细特性。谢谢Steve，但我只是想找一个简单的例子，说明N层ASP.NET与EF 4.1一起工作，它可以在最终提交时工作，并且可以毫无问题地进行CRUD？顺便说一句，对任何感兴趣的人来说，我对STEs都是一场噩梦。完全疼痛。最后，我再次回顾了这一切，并意识到我已经将我的CompiledQuerys放在了一个只在页面生命周期中存在的类中！完全的脸掌！您至少应该将CompiledQuerys移动到应用程序中的静态类，该类将在应用程序范围内存在，以获得编译查询的好处！感谢史蒂夫提醒我出了问题。