Question

我再次能够找到解决方案，以便在我们的业务对象上处理具有辅助对象的列表。

实际上，我们的代码通常如下所示：

public class Object
{
    private List<SubsidiaryObject> subsidiaryObjects = null;
    public List<SubsidiaryObject> SubsidiaryObjects
    {
        get
        {
            if (this.subsidiaryObjects == null)
            {
                this.subsidiaryObjects = DBClass.LoadListFromDatabase();
            }

            return this.subsidiaryObjects;
        }

        set
        {
            this.subsidiaryObjects = value;
        }
    }
}

Con on this：

该属性在表示层中引用并用于DataBinding。释放对实际列表的引用并将其替换为新列表将在GUI中的引用列表中结束，该列表中没有任何内容与对象上的列表相关。

专业人士：

重新加载列表的简单方法（只需将引用设置为null然后再次获取）。

我开发了另一个使用以下模式的类：

public class Object2
{
    private readonly List<SubsidiaryObject> subsidiaryObjects = new List<SubsidiaryObject>();
    public List<SubsidiaryObject> SubsidiaryObjects
    {
        get
        {
            return this.subsidiaryObjects;
        }
    }

    public void ReloadSubsidiaryObjects()
    {
        this.SubsidiaryObjects.Clear();
        this.SubsidiaryObjects.AddRange(DBClass.LoadListFromDatabase());
    }
}

Pro on this：

参考是连续的。

Con on this：

重新加载列表更加困难，因为它无法替换，但必须清除/填充重新加载的项目。

在什么情况下，您最喜欢的方式是什么？

对于其中任何一种模式，您认为Pro / Con是什么？

由于这只是一个普遍的问题，不是针对特定的问题，所以每个答案都是受欢迎的。

Answer 1

您是否需要调用者才能修改列表？如果不是，您应该考虑返回IEnumerable<T>或ReadOnlyCollection。即使你这样做，你也可能最好为Add / Remove制作封面版本，这样你就可以拦截修改。提及内部状态并不是一个好主意IMO。

第三个选项是使用选项2，但每次需要重新填充列表时创建Object2类型的新实例。如果没有问题的附加上下文，那就是我要选择的选项，但可能有理由说明为什么要保留原始实例。

具有附属对象的列表的优缺点

1 个答案: