EF 4.1 N层架构ASP .Net混淆

3

希望您能给我一些建议,非常感谢。

我已经使用EF 4.0一段时间了,使用以下对象上下文管理技术:http://dotnetslackers.com/articles/ado_net/Managing-Entity-Framework-ObjectContext-lifespan-and-scope-in-n-layered-ASP-NET-applications.aspx。我的设置相当简单,有一个Web项目连接到BLL连接到DAL。 Web和BLL引用DAL实体对象。它一直运行良好,但似乎速度很慢。这是一个使用现有数据库模型(即不是代码优先)并指向SQL Server 2005 DB的ASP.NET Webforms应用程序。

无论如何,由于我们在屏幕之间的性能方面遇到了投诉,我现在正在重新审视架构。我已经完成了大部分可能的UI增强,但我认为现在仅保存,重定向和使用EF进行加载就是缓慢的点。

该网站是一系列针对汽车保险的报价页面。我现在希望在会话中创建相关对象,即第1页创建报价对象,填充字段,第2页添加X个附加驾驶员,第3页添加索赔/定罪,然后将对象保存到数据库中。用户可以在报价过程中的任何时候保存并退出,因此保存的位置不总是在最后。我们还需要能够加载第1页的信息,并在单击下一页时在内存中更新它,最后在准备完成报价时更新DB。

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

我已经浏览了各种msdn页面,但我很难将它们全部整合到这个相当简单的应用程序的最新“最佳实践”中。我看过Julie Lerman的视频,但她的n'tier只做了简单的检索和“添加”,可疑地省略了更新部分,因为我认为它并不简单。您认为我应该使用Self Tracking Entities(我已经阅读过人们遇到多个问题,但也许他们的架构更复杂?)或其他一些方法将EF对象存储在会话中并进行更改。

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

1个回答

2
在Session中存储数据可以是最小化IO的有效方法,但这不是一个简单的决定。您不应该在Session State中放置大量数据,我们无法根据您的描述确定您所讨论的数据量或并发活动会话的数量。
还有问题是您的Session State提供程序。如果您使用单个服务器,则可能使用进程内Session State,这很快,但如果您有大量用户和大量数据,则很快就会遇到内存压力问题。
如果您使用Web Farm,则必须使用共享Session State,可能使用SQL Server Session State提供程序,因此您将在每次交互中读取和写入数据库,这可能更糟糕。
然而,第一步是确保您理解问题。不要假设您的性能问题出现在哪里,并尝试重新设计它们。使用分析或仪表技术来识别真正的瓶颈,并集中精力解决这些问题。
您可能会惊讶于问题出现的地方。很可能只是一个数据库优化问题。

感谢您的评论,Steve。我知道会话状态提供程序的差异。我们目前正在使用SQLServer进行存储,最终将考虑迁移到AppFabric。我已经使用过Jetbrains dotrace和SQL分析器等工具,但认为在使用EF 4.1的n层ASP .net时必须有更好的方法。是否有人有任何实际有效的想法或样本架构? - Rick Blyth
这个问题太宽泛了,Rick。有许多潜在的设计方案,而你目前使用的方案和任何其他方案一样有效。我曾经开发过使用基于数据库持久化和基于会话状态的存储库的ASP.NET解决方案,在每种情况下性能都同样良好。事实上,我们刚刚修改了一个应用程序,从基于状态的转向基于数据库持久化的方式。其中一个不一定比另一个更好。你需要找到适合你的应用程序的方案,这取决于其详细特征。 - Steve Morgan
谢谢Steve,但我只是在寻找一个简单的N层ASP .NET示例,它可以与EF 4.1一起工作,并且可以在最终提交时进行CRUD操作而没有问题。 - Rick Blyth
顺便说一句,对于任何感兴趣的人,我在使用STE时遇到了噩梦。非常痛苦。最终我不得不重新审查所有内容,才意识到我把我的CompiledQuerys放在一个只在页面生命周期内存在的类中!真是个大失误!你应该将CompiledQuerys至少移动到应用程序中存在全局的静态类中,以获得编译查询的好处!感谢Steve提醒我有问题。 - Rick Blyth

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接