这是我正在努力解决的情况。我有一个对象模型:
public class MyModel
{
public string Prop1 {get; set;}
public string Prop2 {get; set;}
//etc
}
然后我有对象模型视图
public class MyModelView
{
public MyModel MyModelObject;
public SelectList PropToBeSelected1 {get; set;}
public SelectList PropTobeSelected2 {get; set;}
//etc
}
我还有 MyModelRepository 类,它可以对 MyModel 执行删除、更新操作。
到目前为止一切都很好且清晰。
问题:PropToBeSelected1 和 PropTobeSelected2 是下拉列表,其内容来自数据库。检索这些内容的方法是否应该放入我的 MyModelRepository 中?或者我应该为 ViewModel 创建另一个存储库?
首先,你真的不希望在你的 viewModel 中出现 domian-ish 对象。你的 viewModel 应该是干净的,只有基元(如字符串、整数......等)。所以我建议使用 a AutoMapper 将两个字符串 props 映射到你的 viewModel。
使用选择列表,有很多方法可以解决这个问题,但我可以想象,如果它们是属性列表,那么它们就不是实际的实体,而是值对象。在这种情况下,为它们创建一个存储库就太过了,并且寄宿生的设计也很糟糕。
我将属性列表的“get”放入您的 MyModelRepository 中。类似的东西
_myModelRepository.getProperties1For(myModel);
然后再次打开 AutoMap 以获取您的选择列表。
编辑: 就像 @M.Radwan 指出的,对于复杂的域模型,我将把 viewModels 置于 viewModels 中,以便于映射。
领域模型--
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; }
}
}
根据我们的经验,这是向视图模型添加任何复杂性的唯一原因。我们会将 SelectList 放入 viewModel 中,但最近我们一直在使用内部 viewModel 的 IEnumerables 并调用自定义 EditorFor 或 DisplayFor 将它们转换为下拉列表/复选框/单选按钮列表。
答案是否定的,如果您确实需要此视图,则不应为它们创建任何存储库。所以它们可能是值对象,正如 @jasonhooten 所说,它们应该连接到存储库使用的主聚合对象
最后,在完成视图并使其首先工作之前,我不会决定 ViewModel 结构,这也是我创建并创建 DevMagicFake 的原因,通过使用 DevMagicFake,您将延迟有关 ViewModel 或存储库结构的所有设计决策,或者您将如何使用服务层,所有这些都将在完全完成您的视图并使其首先作为 BDD(行为驱动开发)和 TDD(测试驱动开发)工作后延迟,以便您可以对设计和对象模型做出正确的决策本身
所以我只是创建如下操作方法
public ActionResult List(MyModelView myModelView)
{
FakeRepository<MyModelView> repository = new FakeRepository<MyModelView>();
repository.Add(myModelView);
}
这个假存储库将使我能够保存和检索我的整个模型,即使它是一个复杂的模型,直到我完成并完成整个视图并使其首先工作,然后我开始感谢真正的设计和真正的存储库应该是什么样子,然后继续
有关 DevMagicFake 和此方法的更多信息,请参阅此链接