更像是一个概念问题..。在foreach循环中对我的DataContext进行异步调用有什么不好的原因吗?
private async Task ProcessItems(List<Item> items)
{
var modifiedItems = new List<modifiedItem>();
foreach (var item in items)
{
// **edited to reflect link between items and properties**
// var properties = await _context.Properties
// .Where(p => p.Condition == true).ToListAsync();
var properties = await _context.Properties
.Where(p => p.Condition == item.Condition).ToListAsync();
foreach (var property in properties)
{
// do something to modify 'item'
// based on the value of 'property'
// save to variable 'modifiedItem'
modifiedItems.Add(modifiedItem)
}
}
await _context.ModifiedItems.AddRangeAsync(modifiedItems);
await _context.SaveChangesAsync();
}
由于内部foreach循环依赖于properties
变量,它不是在properties
变量完全实例化之后才开始吗?
由于modifiedItems
变量是在父foreach循环之外声明的,异步将每个modifiedItem
添加到modifiedItems
列表是不是一个坏主意?
在实体框架Linq中是否有任何更适合这种任务的属性/方法?比做嵌入的前端循环更好的主意?
(万一有人想了解情况.IRL,items
是传感器读数的列表。properties
是将原始读数转换成有意义的数据的数学方程,如体积和重量在不同的单位.然后,这些计算出的数据点被存储在数据库中。)
发布于 2018-08-14 04:56:33
不,没有,但是你错过了一些概念。
因为您使用了异步方法,所以ProcessItems
方法应该被称为ProcessItemsAsync
并返回一个task
。
这对你是有用的:异步/等待-异步编程的最佳实践
根据您的需要,建议添加CancellationToken
并考虑异常处理,只是不考虑吞咽例外。
发布于 2018-08-14 05:00:58
这里没有使用异步的问题,一旦您等待异步调用,返回的对象是相同的。
如果您可以在循环之外运行一次DB调用,并过滤内存中的数据以对其进行操作,那么您可能需要重新考虑在foreach中执行DB调用。每个用例都是不同的,您必须确保可以在内存中处理更大的返回集。
通常一次从DB获得1000行的速度比100行快10倍。
发布于 2018-08-14 05:06:22
在这种特殊情况下,我会编写它来加载所有感兴趣的传感器的所有属性的单个列表(考虑所有的items
,并基于您提到的macAddress
/sensorKey
属性),并将其存储在一个列表中。我们叫它allProperties
。我们只进行一次await
,避免重复进行数据库调用。
然后,使用LINQ对象将您的items
连接到它们匹配的allProperties
中的对象。迭代该联接的结果,在循环中没有await
可执行。
https://stackoverflow.com/questions/51841860
复制相似问题