Наследование MVVM с моделями представления
Лучший способ сделать выпадающий список:
grid.Column("PriceType",canSort:true,header: "PriceType",format: @<span>
<span id="spanPriceType_@item.ShoppingCartID">@item.PriceTypeDescription</span>
@Html.DropDownList("PriceType"+(int)item.ShoppingCartID,new SelectList(MvcApplication1.Services.ExigoApiContext.CreateODataContext().PriceTypes.Select(s => new { s.PriceTypeID, s.PriceTypeDescription }).AsEnumerable(),"PriceTypeID", "PriceTypeDescription",Convert.ToInt32(item.PriceTypeId)), new { @class = "PriceType",@style="width:120px;display:none",@selectedvalue="selected"})
</span>),
4 ответа
Как правило, я бы рекомендовал вам не иметь наследования между различными классами ViewModel , а вместо этого иметь наследование напрямую от общего абстрактного базового класса.
Это сделано для того, чтобы избежать вводя ненужную сложность, загрязняя интерфейсы классов ViewModel элементами, которые приходят с более высоких уровней иерархии, но не полностью связаны с основной целью класса.
Связь, которая поставляется с наследованием, также, вероятно, будет сложно изменить класс ViewModel, не затрагивая ни один из его производных классов.
Если ваши классы ViewModel всегда будут ссылаться на один объект модели, вы можете использовать универсальные шаблоны для инкапсуляции этого правила в базовый класс:
public abstract class ViewModelBase<TModel>
{
private readonly TModel _dataObject;
public CustomObjectViewModel(TModel dataObject)
{
_dataObject = dataObject;
}
protected TModel DataObject { get; }
}
public class CustomObjectViewModel : ViewModelBase<CustomObject>
{
public string Title
{
// implementation excluded for brevity
}
}
public class CustomItemViewModel : ViewModelBase<CustomItem>
{
public string Title
{
// implementation excluded for brevity
}
public string Description
{
// implementation excluded for brevity
}
}
Я думаю, проблема здесь в том, что должна быть одна ViewModel для каждого View, а не одна ViewModel для каждой модели.
Причина этого довольно очевидна, так как вы можете только установить один объект должен быть DataContext, этот объект должен быть ViewModel для этого View.
Относительно комментария Энрико выше. ViewModels не должны быть тесно связаны с представлениями, должно быть наоборот. Представления должны быть слабо связаны с ViewModels. ViewModel не должен знать о представлении, это позволяет вам легко проводить модульное тестирование ViewModel. Все взаимодействия между представлениями с ViewModel должны быть реализованы через свойства в ViewModel (свойства ICommand для действий и другие свойства для привязки данных).
Верно только то, что ViewModel тесно связан с моделью, поэтому использование дженериков выше допускает большую расширяемость. Это шаблон, который я бы порекомендовал.
Предоставляя класс ViewModel, который, по сути, просто предоставляет свойства, он должен позволить вам вставить его в любую структуру представления и использовать весь код, который вы использовали ранее. Другими словами, при правильной реализации вы можете перетащить свою сборку ViewModels в приложение ASP.NET MVC и привязать представление к свойствам без изменения кода.
Хорошая статья по основам MVVM: вот эта.
Верно только то, что ViewModel тесно связан с моделью, поэтому использование обобщенных шаблонов выше обеспечивает большую расширяемость. Это шаблон, который я бы порекомендовал.
Предоставляя класс ViewModel, который, по сути, просто предоставляет свойства, он должен позволить вам вставить его в любую структуру представления и использовать весь код, который вы использовали ранее. Другими словами, при правильной реализации вы можете перетащить свою сборку ViewModels в приложение ASP.NET MVC и привязать представление к свойствам без изменения кода.
Хорошая статья по основам MVVM: вот эта.
Верно только то, что ViewModel тесно связан с моделью, поэтому использование обобщенных шаблонов выше обеспечивает большую расширяемость. Это шаблон, который я бы порекомендовал.
Предоставляя класс ViewModel, который, по сути, просто предоставляет свойства, он должен позволить вам вставить его в любую структуру представления и использовать весь код, который вы использовали ранее. Другими словами, при правильной реализации вы можете перетащить свою сборку ViewModels в приложение ASP.NET MVC и привязать представление к свойствам без изменения кода.
Хорошая статья по основам MVVM: вот эта.
Предоставляя класс ViewModel, который в основном просто предоставляет свойства, он должен позволить вам добавить его в любую структуру представления и использовать весь код, который вы использовали ранее. Другими словами, при правильной реализации вы можете перетащить свою сборку ViewModels в приложение ASP.NET MVC и привязать представление к свойствам без изменения кода.
Хорошая статья по основам MVVM: вот эта.
Предоставляя класс ViewModel, который в основном просто предоставляет свойства, он должен позволить вам добавить его в любую структуру представления и использовать весь код, который вы использовали ранее. Другими словами, при правильной реализации вы можете перетащить свою сборку ViewModels в приложение ASP.NET MVC и привязать представление к свойствам без изменения кода.
Хорошая статья по основам MVVM: вот эта. Я действительно считаю, что MVVM - лучшее средство для разработки пользовательского интерфейса. Очевидно, мы не можем все использовать его, потому что для этого требуется создание приложения с нуля с использованием подхода MVVM, но когда вы создаете новое приложение, это не проблема.
Единственное, что у меня вызывает ICommand, это то, что он находится в сборке PresentationCore, которая в основном предназначена для WPF. Если Microsoft хотела ослабить связь, она должна быть вообще в другой сборке.
Мне было бы интересно узнать, есть ли на это лучший ответ, но когда у меня возникала такая же проблема, я всегда включал явное приведение объекта как частное свойство, например итак:
class CustomObjectViewModel : ViewModelBase
{
protected readonly CustomObject CustomObject;
public CustomObjectViewModel( CustomObject customObject )
{
CustomObject = customObject;
}
public string Title
{
// implementation excluded for brevity
}
}
class CustomItemViewModel : CustomObjectViewModel
{
protected CustomItem CustomItem { get { return (CustomItem)CustomObject; } }
public CustomItemViewModel( CustomItem customItem )
:base(customItem)
{
}
}
Это работает, и это лучшее, что я придумал, но никогда не казался мне таким чистым.