C# 分组对象未按预期发生突变
C# grouped objects aren't being mutated as expected
我有一组对象作为 IEnumerable
输入方法,我通过引用 属性 对它们进行分组,然后逐组处理它们。处理涉及改变对象的其他属性。当方法完成并且 returns 时,调用者希望它传入的对象集合发生变化。整个过程是异步的,方法如下所示:
public async Task MutateMyObjects(IEnumerable<MyObjects> myObjects,
CancellationToken cancellationToken)
{
var myObjectsGroupedByGroupingEntity = myObjects
.GroupBy(myObject => myObject.GroupingEntity);
foreach (var myObjectGroup in myObjectsGroupedByGroupingEntity )
{
await ProcessGroup(myObjectGroup.Key, myObjectGroup, cancellationToken);
}
}
MyObject
和 GroupingEntity
都是 类,因此我的期望是 MyObject
作为引用类型传递,并且变异是整个过程中固有的。
实际发生的是 MutateMyObjects
的调用者观察到与方法调用之前观察到的 MyObject
相同的 属性 值。 Task
完成后会观察到这些结果。在调试上述方法时,观察方法returns之前的变量状态,发现变量myObjectGroup
下的对象集合包含变异的属性,而变量myObjects
下的对象集合则没有。
我不确定我理解的哪方面缺失导致我得到错误的期望,任何见解将不胜感激。
问题是我需要先执行 LINQ 查询以具体化对象,然后再将它们发送出去进行更改。问题中未显示的是 IEnumerable<MyObject> myObjects
的表示方式。在我的例子中,myObjects
是延迟执行通过管道传输到对象映射中的数据库提取。这意味着当我改变对象时,groupBy
强制初始化对象,这些对象随后在显示的方法返回时丢失。当“变异”的对象被“使用”时,这些对象实际上被重新初始化了。
正如@Enigmativity 所指出的,在这种方法中,签名可能应该要求 IList<MyObject>
以确保对象的存在,因为该方法打算改变它们。这意味着方法的调用者需要在调用方法之前执行任何 LINQ 查询,从而避免这个陷阱。
我有一组对象作为 IEnumerable
输入方法,我通过引用 属性 对它们进行分组,然后逐组处理它们。处理涉及改变对象的其他属性。当方法完成并且 returns 时,调用者希望它传入的对象集合发生变化。整个过程是异步的,方法如下所示:
public async Task MutateMyObjects(IEnumerable<MyObjects> myObjects,
CancellationToken cancellationToken)
{
var myObjectsGroupedByGroupingEntity = myObjects
.GroupBy(myObject => myObject.GroupingEntity);
foreach (var myObjectGroup in myObjectsGroupedByGroupingEntity )
{
await ProcessGroup(myObjectGroup.Key, myObjectGroup, cancellationToken);
}
}
MyObject
和 GroupingEntity
都是 类,因此我的期望是 MyObject
作为引用类型传递,并且变异是整个过程中固有的。
实际发生的是 MutateMyObjects
的调用者观察到与方法调用之前观察到的 MyObject
相同的 属性 值。 Task
完成后会观察到这些结果。在调试上述方法时,观察方法returns之前的变量状态,发现变量myObjectGroup
下的对象集合包含变异的属性,而变量myObjects
下的对象集合则没有。
我不确定我理解的哪方面缺失导致我得到错误的期望,任何见解将不胜感激。
问题是我需要先执行 LINQ 查询以具体化对象,然后再将它们发送出去进行更改。问题中未显示的是 IEnumerable<MyObject> myObjects
的表示方式。在我的例子中,myObjects
是延迟执行通过管道传输到对象映射中的数据库提取。这意味着当我改变对象时,groupBy
强制初始化对象,这些对象随后在显示的方法返回时丢失。当“变异”的对象被“使用”时,这些对象实际上被重新初始化了。
正如@Enigmativity 所指出的,在这种方法中,签名可能应该要求 IList<MyObject>
以确保对象的存在,因为该方法打算改变它们。这意味着方法的调用者需要在调用方法之前执行任何 LINQ 查询,从而避免这个陷阱。