在我的组织中，我们有一个具有许多不同属性的复杂产品卡。我可以使用Steam产品卡来形象化我正在谈论的内容：http://store.steampowered.com/app/219740/（PS：真棒游戏，检查一下）。
产品卡表示包含title，description，price等属性以及screenshots，reviews，ratings等关联，{ {1}}等
产品细分用于应用程序的不同部分 - 例如，您可以在用户库中找到标记列表（不需要屏幕截图）。
你如何在这里构建阅读模型？
a）尝试创建小型通用视图模型（tags，Screenshot）并将它们组合在具体视图中（Tag，ProductCard）？
b）创建一个神UserLibrary视图模型，它包含与产品相关的每个属性？ （性能方面 - 听起来不太好）
c）为每个视图创建属性定制的视图模型？如果是这样，如果我不得不在整个应用程序中重复使用某些特定部分（产品标题，价格等），我该如何避免代码重复（我们在每个页面上使用部分产品）？
d）？
我不能将事件监听器用作投影仪，因为产品状态是通过我们无法修改的传统CRUD应用程序更改的 - 我们依赖于共享数据库。
答案 0 :(得分：3)
答案是......
为每个视图创建属性定制的视图模型
为什么呢？因为它是最简单，最易维护的解决方案。在阅读环境中，您只需处理只读数据。您不需要封装或粒度表示（特定模型用于＆＃39;屏幕截图＆＃39;标记＆＃39;）。如果您已经拥有它们并且它们具有相同的数据，那么这并不意味着您不能重用任何其他视图模型，但这里的主要原则是创建视图模型以仅为特定视图提供服务。
在此上下文中不存在复制，因为DRY指的是（相同的上下文）行为而不是数据。
答案 1 :(得分：2)
为什么要避免代码重复？或者更具体地说，为什么要避免在不同的有界上下文中进行代码重复;）...如果仅基于避免代码重复而创建依赖项，则会创建错误的抽象（与有效用例无关）。
我将引用桑迪梅斯：
重复比错误的抽象便宜得多
更喜欢重复错误的抽象
{{3}}