我一直在ASP.Net环境中使用LINQ to SQL多年。 UI和BLL层由Web服务分隔，因此延迟加载，更改跟踪等不是一个选项。这在某种程度上很好，因为我们确切地知道代码中发生了什么 - 我们负责持续更改BLL（确定实体是否是新的/更新的），并且由于某些懒惰而没有意外的惊喜 - 加载在某个地方。
我现在已经转移了工作并开始使用新的桌面系统（WPF）。没有边界，即 UI层将直接调用BLL （但请参见最后的警告）。我正在寻找使用EF5，但我对EF提供的功能，选项等数量感到有些不知所措。我希望我能回答几个问题......
是否应跨越边界使用延迟加载？假设我想显示客户及其所有订单，UI是否只是从BLL请求客户，然后使用延迟加载来访问其订单？在UI中执行此操作对我来说不合适。我假设延迟加载只是你在BLL中使用的东西。
我相信您可以使用DbContext.Configuration.LazyLoadingEnabled关闭延迟加载，但是如果我想在BLL中使用延迟加载，但是当我将实体返回到我的UI时，我不会想让UI进行任何延迟加载吗？
如何更改跟踪，自我跟踪实体和POCO？我什么时候应该用？当我使用LINQ to SQL时，这对我来说从来都不是问题（它是跨Web服务，而ASP.Net因此没有“状态”，因此更改跟踪无关紧要）。我觉得我想要将它全部停用（这是我习惯的），但我担心我会错过一些EF“善良”。我想我担心不能控制持久数据。
由于我一直在玩并使用EF检索数据，我在一些实体层次结构中注意到某些属性集合（例如customer.Orders）包含“代理”实体。这些是什么以及何时有用？
我再次注意到你可以通过DbContext.Configuration.ProxyCreationEnabled关闭代理，但是文档显示它还有更多内容，以及与LazyLoadingEnabled设置的某种关系？
EF“代码优先”似乎越来越受欢迎。它给你带来了什么？我习惯在SSMS中设计我的数据库，而不是编写很多类，注释等等！
最后一点需要注意 - 虽然应用程序的UI层直接调用BLL中的方法，但是有一个小机会，以后我们可能希望将它们分开（例如，通过Web服务）。这将如何影响设计考虑因素，以及我上面提出的一些问题？
道歉，将多个问题捆绑在一起。如果我能得到答案，那么希望这对我未来的其他人有用。
答案 0 :(得分：1)
在我看来，延迟加载设计用于UI层而不是BLL。它在数据绑定方案中特别有用，例如在主 - 详细信息视图中。如果您的UI中有客户列表，并且通过单击客户，用户可以显示客户的订单，则可以通过延迟加载来加载这些订单。由于您事先不知道用户将点击哪些客户，否则如果您不想使用延迟加载（或实现您自己的事件驱动的子加载机制），您将被强制加载所有客户的所有订单。 ）。这会产生不必要的开销。
另一方面，我无法理解为什么BLL中的延迟加载会很有趣。通常，您知道必须加载哪些数据才能执行特定的业务逻辑。当您知道它时，您可以使用急切或显式加载。编写代码只需要一行或两行代码，而不仅仅是访问导航属性并依赖于延迟加载，但是通过热切和显式加载，您可以清楚地了解代码的作用以及何时访问数据库。
请记住，延迟加载需要一个尚未处理的上下文，因此只要使用UI（或部分UI），就必须以上下文的方式设计BLL。
如果您不想在UI层中进行延迟加载，请将其关闭并在BLL中使用预先加载和显式加载。加载了启用了延迟加载的实体后，无法关闭延迟加载。
自我跟踪实体在新项目中已弃用或至少the EF team suggests to not use them anymore（第二个参考：http://msdn.microsoft.com/en-us/data/jj613668）。他们还建议to not use EntityObject derived entities anymore。因此，POCO绝对是最佳选择。
更改跟踪本身是EF的核心功能，也可用于两种不同形式的POCO：作为“基于快照”的更改跟踪和更改跟踪代理。默认值是基于快照的更改跟踪。变更跟踪代理可用于提高某些情况下的性能 - 尤其是涉及数千个实体且需要在单个上下文中更新时。有关更改跟踪代理的更多信息，请访问：http://blog.oneunicorn.com/2011/12/05/should-you-use-entity-framework-change-tracking-proxies/
如果启用了延迟加载或动态更改跟踪，则EF会从POCO实体创建代理。它们是从您的实体类派生的动态对象，需要进行延迟加载和动态更改跟踪（=不基于快照）。
将ProxyCreationEnabled设置为false会禁用任何代理创建 - 用于动态更改跟踪和延迟加载。如果代理创建已关闭，则LazyLoadingEnabled的设置无关紧要。更多详情请点击此处：https://stackoverflow.com/a/7112470/270591
如果您对数据库第一种方法感觉更舒服，那么请使用它。它同样受到代码优先或模型优先支持，并且 - 作为基于EDMX的方法 - 甚至还有一些代码优先没有的高级功能。有关不同策略的更多详细信息，请访问：https://stackoverflow.com/a/5446587/270591
...虽然应用程序的UI层直接调用BLL中的方法， 将来我们可能想要分开的可能性很小 他们（例如通过网络服务）。这将如何影响设计 考虑因素，以及我上面提出的一些问题？
您将无法再在UI层中使用延迟加载，因为您无法通过Web服务边界传递上下文实例。延迟加载将变得像在UI是（断开连接的）远程浏览器的Web应用程序中一样无用。您还将失去跟踪附加实体的变化的舒适度。为连接实体和对象图建立变更集比利用连接实体的变更跟踪更困难。因此，这种“小机会”可能会对整个应用程序设计产生深远的影响。