我正在尝试制作一个程序,通过匹配他们的偏好来帮助将人员组合在一起。
但在我结合之前,我已经遇到过这种情况的viewmodels问题。
我们估计以下几个类:
public class Person
{
public string Name;
public List<Preference> PartnerPreferences;
}
public class Preference
{
public Person Partner;
public int Preference; //-1 does not want as partner / +1 does want as partner
}
我现在可以创建相应的viewmodels VMPerson和VMPreference。 如果我像往常一样这样做,那么VMPerson的构造函数就会有这样的内容:
foreach (Preference pref in _person.PartnerPreferences)
{
PartnerPreferences.Add(new VMPreference(pref));
}
PartnerPfreferences
是Observablecollection<VMPreferences>
在VMPreference中:
Person = new VMPerson(_preference.Person);
但是当我想从一个简单的模型创建视图模型时,我将遇到一个生成无限视图模型的循环。
示例:
The model has 2 persons, A and B. A wants B as his partner and B wants A as his partner.
Creating viewmodel for A
-> In VMPartner constructor, preferences of person A get wrapped in viewmodels
-> In VMPreference constructor, person B gets wrapped in viewmodel
-> In VMPartner constructor, preferences of person B get wrapped in viewmodels
-> In VMPreference constructor, person A gets wrapped in viewmodels
[And from here it will start all over again]
(Since the constructor of VMPreference can not know that person A already
has a viewmodel and he could stop here, setting the already existing
viewmodel in place)
我看到的唯一解决方案是使VMPreference成为仅包含string Name
和int Preference
的VM。但这会禁用许多内容,比如使用Preferences.Add(new VMPreference(SelectedPerson))
,也会使Viewmodel复杂化为模型转换。
我很感谢有关如何解决这个问题的任何提示和想法。
答案 0 :(得分:1)
你说从这里它将重新开始,这不一定是真的,这完全取决于你走多远。视图模型仅包装您为其提供的数据。因此,如果您没有为实际设置为Person
B的合作伙伴的Person
A提供任何首选项,那么就不会有循环。
此外,如果您只是制定一个规则,Person
对象设置为Partner
属性值没有首选项,那么您将同样避免所有循环。实际情况是并非所有Person
个对象都需要设置所有属性。
您可以确保主级别上的所有Person
个对象都已完全填充,但Partner
属性中引用的对象不是,只需要具有您需要的任何属性值。
答案 1 :(得分:0)
您是否需要优先考虑与完整的人有关?看起来好像你可能会有第三个更简单的人引用类,它不包括首选项集合。当然,除非你想要大量相互关联的偏好来遍历。你现在的班级甚至可以扩展它。
在实体框架中以导航属性的形式处理相同问题的另一个想法是使数据源中的集合延迟加载。这样,只有在调用get时才会分配首选项对象中的person属性。