ASP.Net中的实体框架最佳实践

Question

我刚开始致力于一个ASP.net应用程序中的实体框架，我想知道是否有人可以指出最佳实践的正确方向。我有以下列出的一些问题。

1. 首先我使用的是实体框架4.0。我已经创建了我的数据库，因此我创建了一个类库，并从数据库中生成实体模型。我一直在使用数据库生成的Guids，所以我必须修改ssl以包含属性StoreGeneratedPattern="Identity"。有没有办法自动做到这一点，或者我每次更新数据库和模型时都必须手动编辑ssl？ （对于那些你知道正面临问题的GUID或想知道为什么我这样做.. this is a clear article对自动生成的GUID问题）

2. 我打算在类库中使用单个文件保存所有的数据库查询。这是好的做法吗？我如何确保不同的程序员不会一遍又一遍地重写相同的查询？

3. 我打算在每种方法中使用独特的上下文。这是正确的路吗？我通过Rick Strahl's post了解了上下文生命周期管理。但我仍然不确定每种方法的独特上下文是否是正确的方法。

4. 我可以将我的数据库查询作为静态方法使用，因为它们没有使用任何实例变量？

5. 如果我使用每个方法的独特上下文，如3所述，并且我希望修改由一个上下文返回的实体对象，那么最佳实践是什么？我是否使用附加功能将对象附加到新的上下文并保存更改？我没有试过这个，但我已经阅读了几篇文章，看起来有点直接，但想知道是否有任何替代方案。

如果您有任何关于如何在ASP.net应用程序中使用实体框架的建议，我绝对可以使用帮助。这是我第ASP.net/Entity框架应用程序，这样任何提示将帮助

Answer 1

1. 这是问题在2010年的VS最初版本在某些情况下，这应该已经正确的，一旦你安装了VS 2010 SP1工作。如果它不安装这个KB。
2. 你可以很容易地用很多静态方法获得巨大的类。尝试使用您正在查询的实体类型进行一些分离。你永远不会完全确保另一个程序员不会再次创建相同的查询。这是关于正确的查询命名遵循相同的命名策略，文档和程序员之间的通信。
3. 通常不需要“每个方法”的唯一上下文。在大多数情况下，您应该对每个逻辑（业务）事务的独特上下文感到满意 - 万一Web应用程序逻辑操作在大多数情况下是单个请求处理=每个请求一个上下文。
4. 如果您将上下文实例传递给您的查询，那么答案是肯定的。一旦你不将它们创建为静态，并且它们将从它们的类实例中获取上下文实例，那么您将非常接近存储库模式。
5. 这正是上下文每个方法的问题，而且很难解决，因为要使这项工作您必须首先从第一个上下文中分离实体并将其附加到第二个上下文。如果您的实体也加载了相关实体，则所有这些关系在分离期间将被清空（除非您使用深层克隆而不是detaching =创建实体的第二个实例）。