我与一位资深的.NET架构师合作，我们进行了许多有建设性的争论，并且在过去的6个月中，我通常在我们的讨论中认输。通过与他的合作，我学到了很多东西。但是，我们目前存在一个设计问题，我们对此持不同意见，我想听听其他人的意见/建议，因为他还没有说服我接受他的观点，我会坚持自己的观点，直到有人能给我证据证明我错了。
我们使用Entity Framework 4.0，并在不同的模型中同时使用持久化感知和Self Tracked Entities。我们开始使用Self Tracked Entities来跟踪对Entity Graphs的更改，这些Entity Graphs通过WCF传输到我们的Silverlight应用程序。它运行得非常好。我们也开始将Self Tracked Entities用于我们不通过WCF传输的模型，但许多模型仍然保持持久化感知Entities/Models的状态。
我的同事认为，Entity Framework的ObjectContext应该尽可能短暂地存在。他坚持认为，它只应该在执行查询和持久化所需的时间内存在。任何与Entities相关的业务工作都应该是分离的。对于我们拥有的每个Entity Model，我们都有一个查询类和一个持久化类，两者都是IDisposable的，并且在实例范围内具有ObjectContext和方法中的查询/持久化逻辑。我们在业务逻辑中使用这些查询/持久化类，而不是直接在业务逻辑中使用ObjectContext。当构造这些类实例时，ObjectContext也会被构造，当它们被Disposed时，ObjectContext也会被Disposed。这些类就像我们的LINQ操作的包装器，将EF与业务逻辑分离，并协助LINQ查询的重用。
现在首先考虑非Self Tracked Entities：
我理解他为什么想要这样做，以及不希望有一个长时间运行的ObjectContext的愿望，但我的问题是，他总是希望即使是微不足道的业务逻辑也与ObjectContext分离，而且我们的设计下有一个单独的查询和持久化上下文，意味着没有ObjectContext对我们的业务逻辑中使用的Entities进行状态跟踪。对于非Self Tracked Entities，这意味着如果我们在业务逻辑中修改Entities，则必须在持久化之前手动设置这些Entities的Modified状态。当持久化复杂图形并进行多个更改时，这真的很麻烦。此外，我怀疑我们无法像EF自动执行的那样手动执行它。
对于我们的Self Tracked Entities，情况也是一样的，因为只有在反序列化图形时才会启用跟踪，所以在服务内部工作时，即使从Context中分离，Self-Tracked Entities仍然没有跟踪。
我的问题是，Entity Framework的最佳实践是什么，如何设计一个Entity Framework数据访问层？ObjectContext应该存在多长时间？业务逻辑是否总是与ObjectContext分离？如果是，那么在脱离ObjectContext时如何进行状态跟踪？我正在考虑的一个选项是将所有实体转换为自跟踪实体，并使用一些图遍历代码来遍历查询的图形并为图中的所有实体打开跟踪，以便即使在服务端工作时也打开了自跟踪（基本上模仿了当自跟踪实体图被反序列化时发生的情况）...
我不建议我们长时间保存ObjectContext，但在查询和持久化之间脱离并失去ObjectContext状态跟踪的好处似乎很愚蠢...我们正在失去EntityFramework的一个巨大优势...
抱歉发帖太长了...任何帮助都会感激。
我们使用Entity Framework 4.0，并在不同的模型中同时使用持久化感知和Self Tracked Entities。我们开始使用Self Tracked Entities来跟踪对Entity Graphs的更改，这些Entity Graphs通过WCF传输到我们的Silverlight应用程序。它运行得非常好。我们也开始将Self Tracked Entities用于我们不通过WCF传输的模型，但许多模型仍然保持持久化感知Entities/Models的状态。
我的同事认为，Entity Framework的ObjectContext应该尽可能短暂地存在。他坚持认为，它只应该在执行查询和持久化所需的时间内存在。任何与Entities相关的业务工作都应该是分离的。对于我们拥有的每个Entity Model，我们都有一个查询类和一个持久化类，两者都是IDisposable的，并且在实例范围内具有ObjectContext和方法中的查询/持久化逻辑。我们在业务逻辑中使用这些查询/持久化类，而不是直接在业务逻辑中使用ObjectContext。当构造这些类实例时，ObjectContext也会被构造，当它们被Disposed时，ObjectContext也会被Disposed。这些类就像我们的LINQ操作的包装器，将EF与业务逻辑分离，并协助LINQ查询的重用。
现在首先考虑非Self Tracked Entities：
我理解他为什么想要这样做，以及不希望有一个长时间运行的ObjectContext的愿望，但我的问题是，他总是希望即使是微不足道的业务逻辑也与ObjectContext分离，而且我们的设计下有一个单独的查询和持久化上下文，意味着没有ObjectContext对我们的业务逻辑中使用的Entities进行状态跟踪。对于非Self Tracked Entities，这意味着如果我们在业务逻辑中修改Entities，则必须在持久化之前手动设置这些Entities的Modified状态。当持久化复杂图形并进行多个更改时，这真的很麻烦。此外，我怀疑我们无法像EF自动执行的那样手动执行它。
对于我们的Self Tracked Entities，情况也是一样的，因为只有在反序列化图形时才会启用跟踪，所以在服务内部工作时，即使从Context中分离，Self-Tracked Entities仍然没有跟踪。
我的问题是，Entity Framework的最佳实践是什么，如何设计一个Entity Framework数据访问层？ObjectContext应该存在多长时间？业务逻辑是否总是与ObjectContext分离？如果是，那么在脱离ObjectContext时如何进行状态跟踪？我正在考虑的一个选项是将所有实体转换为自跟踪实体，并使用一些图遍历代码来遍历查询的图形并为图中的所有实体打开跟踪，以便即使在服务端工作时也打开了自跟踪（基本上模仿了当自跟踪实体图被反序列化时发生的情况）...
我不建议我们长时间保存ObjectContext，但在查询和持久化之间脱离并失去ObjectContext状态跟踪的好处似乎很愚蠢...我们正在失去EntityFramework的一个巨大优势...
抱歉发帖太长了...任何帮助都会感激。