这是我正在努力的情况。 我有一个对象模型:
public class MyModel
{
public string Prop1 {get; set;}
public string Prop2 {get; set;}
//etc
}
然后我有Object ModelView
public class MyModelView
{
public MyModel MyModelObject;
public SelectList PropToBeSelected1 {get; set;}
public SelectList PropTobeSelected2 {get; set;}
//etc
}
我还有MyModelRepository类,可以执行MyModel的删除,更新操作。
到目前为止一切都很好。
问题: PropToBeSelected1和PropTobeSelected2是下拉列表,其内容来自数据库。检索这些内容的方法应该放在我的MyModelRepository中吗?或者我应该为ViewModel创建另一个存储库吗?
谢谢。
答案 0 :(得分:1)
首先,你真的不想在viewModel中使用domian-ish对象。你的viewModel应该是干净的,只有原语(比如字符串,整数等)。所以我建议使用a AutoMapper将你的两个字符串道具映射到你的viewModel。
使用选择列表,有很多方法可以解决这个问题,但我可以想象如果它们是属性列表,那么它们不是实际实体,而是值对象。在这种情况下,为他们创建一个存储库是过度杀死和寄宿生坏设计。
我将属性列表的'get'放在MyModelRepository中。像
这样的东西_myModelRepository.getProperties1For(myModel);
然后再次打开AutoMap以获取您的选择列表。
编辑: 就像@ M.Radwan指出的复杂域模型一样,我将使viewModel成为一个非常容易映射的viewModel。
域模型 -
public class User : Entity
{
public Address Address { get; set; }
}
public class Address
{
public string Street { get; set; }
public string Zip { get; set; }
}
将映射到
public class DetailsViewModel
{
public int Id { get; set; }
public string Name { get; set; }
public AddressViewModel Address { get; set; }
public class AddressViewModel
{
public string Street { get; set; }
public string Zip { get; set; }
}
}
根据我们的经验,这是为viewModel添加任何复杂性的唯一原因。我们将SelectLists放在viewModel中,但最近我们一直使用内部viewModel的IEnumerables并调用自定义EditorFor或DisplayFor将它们变成复选框/单选按钮的下拉列表/列表。
答案 1 :(得分:1)
答案是否定的,如果您真的需要这个视图,则不应为它们创建任何存储库。所以他们可能是@jasonhooten说的价值对象,他们应该连接到存储库使用的主聚合对象
最后我决定ViewModel结构,直到我完成视图并使其首先工作,这就是我创建和创建DevMagicFake的原因,通过使用DevMagicFake,您将推迟有关ViewModel结构或设计的所有设计决策存储库或您将如何使用服务层,所有这些将在完全完成您的视图后延迟,并使其首先作为BDD(行为驱动开发)和TDD(测试驱动开发)工作,以便您可以做出正确的设计决策和对象模型本身
所以我只需创建动作方法,如下所示
public ActionResult List(MyModelView myModelView)
{
FakeRepository<MyModelView> repository = new FakeRepository<MyModelView>();
repository.Add(myModelView);
}
这个假存储库将使我能够保存和检索我的整个模型,即使它是一个复杂的模型,直到我完成并完成整个视图并使其首先工作,然后我开始感谢真实设计和真实存储库应该如何
看起来像和做什么有关DevMagicFake的更多信息,请参阅此链接