Linq/数据对象最佳实践
我是一名新的 ASP.NET 程序员，我刚刚问了这个问题这给我留下了一个更通用的答案。
当前关于 Linq 和数据对象的最佳实践是什么？具体何时进行；变暗、新并处理掉它们。
另外，在同一页面上的许多不同范围中使用的对象（例如用户数据对象）又如何呢？它们应该是模块级别的还是在每个范围中创建的？
如果有人能给我有关当前最佳实践的悬崖笔记，甚至是描述它们的文章的链接，我将不胜感激。
I am a new asp.net programmer and I just asked this question which left me with a more general one.
What is/are the current best practices regarding Linq and data objects? Specifically when to; dim, new and dispose of them.
Also what about objects that get used in many different scopes on the same page e.g. a user data object. Should they be module level or created in each scope?
If someone could give me the cliff notes on the current best practices or even a link to an article which describes them I would greatly appreciate it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
快速思考（我正在开会，太糟糕了）
对于 ASP.NET，数据上下文的最大生命周期是一次发布或回发。您可以创建更多，但它们都会随着页面卸载而消失。是的，您应该明确地处置它们； using 语句是处理该问题的最佳方法，因为它会在块结束时自动调用 dispose：
从 LINQ 查询返回的数据不会随数据上下文一起消失，但此时它不再连接到上下文，并且可以进行更改不再用于更新数据库。 （您始终可以创建新上下文，然后附加为新对象，或者重新查询并合并更改，或者满足您的需求的任何内容。）
请务必注意，LINQ 查询在需要评估数据之前不会执行。在数据上下文被释放时保留查询是一个非常容易的错误，然后当查询需要运行时，它就不能运行，因为它是使用不再存在的数据上下文创建的。有两种一般方法可以解决这个问题。
强制执行查询，通常使用 .ToList() 或其他一些会生成数据集合的方法：
List myCustomers = (from c in nw.Customers select c).ToList();
这将运行查询，将数据复制到可枚举集合中，并为您提供一个可以返回给方法调用者的集合。但是，这些对象现在与上下文分离，因此它们不能用于更新。
如果您使用 LINQ 进行 CRUD，那么最好使用一个数据上下文来执行所有更新、删除和插入，然后对所有更改调用一次 SubmitChanges()。这确保它们作为单个事务运行。 （如果还没有正在运行的事务，数据上下文将为每个 SubmitChanges 调用生成一个事务。）
如果要在查询中选择一个项目，请使用 FirstOrDefault() 而不是 First()。如果没有任何内容满足选择标准，First() 将抛出异常，而 FirstOrDefault() 将返回 null。了解非常有用。
除此之外，享受乐趣并尝试很多东西。 LINQ 将改变您思考数据的方式。
Quickie thoughts (I'm sitting in a meeting, so bad me)
For ASP.NET, the maximum lifetime of a data context is one post or postback. You can create more than that, but they will all die with the page unload. Yes, you should dispose of them explicitly; the using statement is the best way to handle that because it will automatically call dispose when the block ends:
Data that's returned from a LINQ query does not disappear with the data context, but at that point it's no longer connected to a context and changes can't be used to update the database any more. (You can always create a new context, then attach as a new object, or re-query and merge changes, or whatever meets your needs.)
Be very aware that a LINQ query doesn't execute until it needs to evaluate the data. It's a very easy mistake to hold onto a query while the data context gets disposed, then when the query needs to run, it can't, because it was created with a data context that no longer exists. There are two general ways to cope with this.
Force the query to execute, usually with .ToList() or some other method that will generate a collection of data:
List myCustomers = (from c in nw.Customers select c).ToList();
This runs the query, copies the data into an enumerable collection, and gives you a collection that can be returned to a method caller. However, these objects are now separate from the context, so they can't be used for updates.
If you're doing CRUD with LINQ, it's a good idea to use one data context for all updates, deletes, and inserts, then call SubmitChanges() once for all the changes. This ensures that they run as a single transaction. (The data context will generate a transaction for each SubmitChanges call, if there isn't a transaction already running.)
If you want to select one item in a query, use FirstOrDefault() rather than First(). First() will throw and exception if nothing meets the selection criteria, while FirstOrDefault() will return a null. Very useful to know.
Beyond that, have fun and try lots of stuff. LINQ will change the way you think about data.
通常，您希望将正在操作的数据作为参数传递给函数，并将类型的依赖项作为构造函数参数传递。因此，例如 linq 数据上下文可能是您的类型所依赖的操作，因此应该注入到构造函数中。用于在上下文中查找数据的值会快速变化，并在同一上下文中重复使用，因此将是您类型的函数参数。
然而，如果您的类型被构建为在其生命周期内对多个上下文执行操作，您可能会考虑将上下文作为函数参数传递，但这可能更表明存在设计问题。
至于在类型的函数作用域内实例化数据上下文，实际上没有任何理由在函数中产生这种开销，除非保证类型的生命周期仅持续函数调用本身的生命周期。即使现在是这种情况，将来的某个时候也可能不会，因此最好在设计类型时考虑到这种情况。
Generally you want to pass data being operated on as parameters to functions and dependencies of types as constructor arguments. So for instance a linq data context is likely going to be something your type depends on to operate, and should therefore be injected in the constructor. The values you use to look up data in your context will change rapidly and be used repeatedly for the same context, and therefore would be function parameters on your type.
If it is the case however that your type is built to perform operations on multiple contexts within its lifetime, you might consider passing the context as function parameters, but this would probably indicate a design problem more than anything else.
As for instancing data contexts within function scopes of a type, there really isn't any reason to have that overhead in your functions unless the lifetime of your type is guaranteed to only last the lifetime of the function call itself. Even if that is the case right now, it might not be at some point in the future and so it is still better to design your types with that case in mind.