我正在创建一个游戏,我有很多不同的页面。例如:loginpage,profilepage,playersfriendeditpage。
我是否为每个人创建了一个ViewModel?他们都在处理模型,“玩家”,但在不同方面。什么是常识?
答案 0 :(得分:1)
因为视图模型从视图中充当模型的接口,所以只要视图需要以不同于任何其他视图的方式修改模型,您就会想要一个新的视图模型。
换句话说,即使各种视图可能看起来不同,但是与模型/视图模型的交互决定了是否需要新的视图模型。
答案 1 :(得分:1)
如果您的网页包含大量内容,则将它们分解为子虚拟机可能是有意义的。我试着将ViewModel视为一个类,就像任何其他类一样,如果它没有意义,你不希望它做任何事情。如果您的页面在逻辑上被分解为迷你视图,那么您应该能够轻松地在子VM中包含这些需求。
例如:假设您有一个包含所有信息的编辑页面。也许用户信息(名称,地址,电话号码)是一个虚拟机,工作历史是一个虚拟机,爱好部分是一个虚拟机,你的主虚拟机基本上完成了它周围的所有工作。您可以使用消息传递和/或事件来处理通信需求。
答案 2 :(得分:0)
当您想要创建包含另一个模型的实例的模型时,ViewModel非常有用。例如,当您在一个模型与另一个模型(一个表和另一个表)之间存在1对多的关系并且需要在同一视图上显示这两个信息时就是这种情况。或者甚至不是1对多,但通常情况就是这样。
如果您的下拉列表包含从数据库中的表中填充的值,但您的View应显示来自其他模型的所有其他信息,例如,您将在此示例中使用ViewModel。
答案 3 :(得分:0)
我将ViewModel定义为视图的抽象。 viewModel应包含提供数据和行为视图需要正常运行。
根据这个定义,我的本能是为每个视图提供一个单独的viewModel,因为它们各自可能有自己独特的行为。
所有视图都依赖于同一个Player
实体这一事实是一个实现细节,并且已经建议将此功能移动到其他viewModel可以派生的基类中,类似于这样:
public abstract class ScreenViewModel : ViewModelBase // Implements INotifyPropertyChanged
{
private Player _currentPlayer;
public ScreenViewModel(IRepository<Player> playerRepository)
{
// Retrieve desired player from the repository.
this._currentPlayer = playerRepository.Find(...);
}
// This is an idea of the sort of thing you can do; derived viewModels
// do not need to worry about loading the player, they can just consume
// it and provide the screen specific behaviour.
protected Player CurrentPlayer
{
get { return _currentPlayer; }
}
}
我不同意目前接受的答案中提供的建议,因为它是错误的;你的观点应该塑造你的viewModels而不是你的数据库。数据库的设计应该对viewModel的设计很少或没有影响。在视图和域层之间建立viewModel的重点是将应用程序与较低层中的更改隔离开来。
事实上,如果你看一下我提供的示例viewModel,它可以很好地隔离那些变化。播放器通常会被暴露为POCO(使持久性无知),并且提供对这些实体的访问的存储库隐藏在接口后面。
这意味着我可以改变数据库结构的实现方式,这些更改将被数据层吸收(例如,通过改变实体框架将表映射到应用程序中的实体的方式),并且viewModel不需要更改。您甚至可以更改持久性机制(IE将数据保存到自定义文件而不是数据库),只要它将数据映射到Player
POCO并且新存储库实现了{view}模块的IRepository<Player>
接口仍然会按预期工作,证明数据库结构对viewModel的设计几乎没有影响。
答案 4 :(得分:-1)
这取决于您设计数据库的方式。 如果您希望所有字段都在同一个表中,您可以将它们保存在同一个视图模型中,大多数情况并非如此,因为您不希望在数据库中有任何冗余信息而您希望数据库要规范化。因此,您可以根据数据库设计构建模型,以便数据库没有冗余信息。