将逻辑放在ViewModel geters中
您如何将Get-logic放入ViewModel的getter中？ 就像是：
public class DummyViewModel { public int Id { get; set; } private DummyObject myObject; public DummyObject MyObject { get { if (MyObject == null) { DummyRepository repo = new DummyRepository(); myObject = repo.Get(Id); } return myObject; } } } 这是不好的做法，还是完全没问题？ 通过在那里完成所有的get-logic，我发现我的控制器变得非常臃肿，但我真的很沮丧，我应该把它放在哪里……
我这样做的原因是我可以将ViewModel传递给不同类型的视图，并且只根据请求的属性执行必要的DB查找。
将逻辑放入VM中的getter中没有任何问题 – VM的作用是将数据呈现给视图，并且它应该尽可能地“查看”（View不应该做太多（如果任何）在显示之前对数据进行整形的工作）。
例如，我在我的VM中使用名为GetAvailableClients属性，这将是View绑定到的属性之一。 该特定getter的工作是过滤数据 – IOW提供从完整列表（也保存在VM中）中选择的减少的数据集，通常使用LINQ过滤数据，这意味着我已经放置了一些自定义逻辑在吸气剂中。
我不喜欢的是你的方法的其余部分，如果属性没有被填充，它将进入存储库并获取数据本身。 对我来说这是一个禁忌，财产完全违反了单一责任原则，使财产责任过多。 更何况，一旦你开始将该属性绑定到UI，这不是一个好习惯 – 突然你的应用程序将在用户执行操作时开始挂起，因为你的属性获取器已被触发并且它已决定调用数据库或web服务，并且更糟糕的是，在UI线程上完成了调用….它只是变得丑陋。
就个人而言，我的视图模型中没有任何逻辑 – 它们是非常愚蠢的DTO。 我当然不会让VM负责它自己通过存储库加载。
你的问题是通用的，但我会尽我所能回答。
我不喜欢这些东西：
1）可测试性。 您的属性正在创建存储库，您将如何模拟存储库并对其进行测试？
2）延迟加载。 延迟加载是潜在的性能损失，视图模型不应该这样做。 如果将viewmodel绑定到包含数百个条目的网格会发生什么？
3）公开Id。 您的Id属性（我假设是实体的主键值）有一个setter。 您是否要在视图中显示此ID？ 如果没有，摆脱它，如果是，删除setter。 setter意味着视图必须执行某种商业function才能查找正确的值，这会破坏SoC。