我是一个新的 asp.net 程序员,我刚刚问了这个问题,这给我留下了一个更普遍的问题。
目前关于 Linq 和数据对象的最佳实践是什么?具体何时;暗淡、新的并丢弃它们。
此外,在同一页面上的许多不同范围内使用的对象(例如用户数据对象)又如何呢?它们应该是模块级别还是在每个范围内创建?
如果有人能给我关于当前最佳实践的悬崖笔记,甚至是描述它们的文章的链接,我将不胜感激。
我是一个新的 asp.net 程序员,我刚刚问了这个问题,这给我留下了一个更普遍的问题。
目前关于 Linq 和数据对象的最佳实践是什么?具体何时;暗淡、新的并丢弃它们。
此外,在同一页面上的许多不同范围内使用的对象(例如用户数据对象)又如何呢?它们应该是模块级别还是在每个范围内创建?
如果有人能给我关于当前最佳实践的悬崖笔记,甚至是描述它们的文章的链接,我将不胜感激。
快速的想法(我正在开会,我太糟糕了)
对于 ASP.NET,数据上下文的最长生命周期是一个 post 或 postback。您可以创建更多内容,但它们都会随着页面卸载而消失。是的,您应该明确处置它们;using 语句是最好的处理方式,因为它会在块结束时自动调用 dispose:
using (NorthwindModel nw = new NorthwindModel())
{
do stuff
}
从 LINQ 查询返回的数据不会随着数据上下文消失,但此时它不再连接到上下文,并且无法再使用更改来更新数据库。(您始终可以创建一个新上下文,然后附加为一个新对象,或者重新查询和合并更改,或者满足您的需求。)
请注意,LINQ 查询在需要评估数据之前不会执行。在处理数据上下文时保留查询是一个非常容易的错误,然后当查询需要运行时,它不能,因为它是使用不再存在的数据上下文创建的。有两种一般的方法可以解决这个问题。
强制执行查询,通常使用 .ToList() 或其他会生成数据集合的方法:
List myCustomers = (from c in nw.Customers select c).ToList();
这会运行查询,将数据复制到一个可枚举的集合中,并为您提供一个可以返回给方法调用者的集合。但是,这些对象现在与上下文分离,因此它们不能用于更新。
如果您使用 LINQ 进行 CRUD,最好使用一个数据上下文进行所有更新、删除和插入,然后为所有更改调用一次 SubmitChanges()。这确保它们作为单个事务运行。(如果没有正在运行的事务,数据上下文将为每个 SubmitChanges 调用生成一个事务。)
如果要在查询中选择一个项目,请使用 FirstOrDefault() 而不是 First()。如果没有任何内容符合选择条件,First() 将抛出异常,而 FirstOrDefault() 将返回 null。知道非常有用。
除此之外,玩得开心并尝试很多东西。LINQ 将改变您对数据的看法。
通常,您希望将正在操作的数据作为参数传递给函数,并将类型的依赖关系作为构造函数参数。因此,例如 linq 数据上下文可能是您的类型所依赖的操作,因此应该注入构造函数中。您用于在上下文中查找数据的值将迅速变化并在同一上下文中重复使用,因此将成为您类型上的函数参数。
但是,如果您的类型被构建为在其生命周期内对多个上下文执行操作,您可能会考虑将上下文作为函数参数传递,但这可能比其他任何事情都更能表明设计问题。
至于在类型的函数范围内实例化数据上下文,实际上没有任何理由在函数中产生这种开销,除非保证类型的生命周期仅持续函数调用本身的生命周期。即使现在是这种情况,将来也可能不会,因此最好在设计类型时考虑到这种情况。