在支持支持不同维度数据的更复杂的UI方面，我正在努力为查询建模和读取模型。
想象一下我有一个OrderDetailView的场景，该屏幕用于显示订单的详细信息（订单行等）。>>
现在想象一个显示相同订单详细信息的屏幕，以及可以为该订单提供服务的送货公司列表。
问题：
我是否为此屏幕创建一个单独的ViewModel？我很难命名，但也许像OrderDeliveryView这样的东西？或AssignDeliveryToOrderView。对于这些更复杂的屏幕，以最终执行的操作命名是一个好习惯吗？
我们的读取模型位于SQL数据库中。我看到的唯一存储订单明细的方法以及该视图的送货公司列表使用的是两个单独的表。这两个表将通过OrderDeliveryView规范化程序从相关事件中进行更新。
如果是这种情况，最好只使用现有的OrderDetailView并从UI中调用第二个查询：GetAvailableDeliveryCompanies，该查询将返回DeliveryCompanyListView。这些模型更紧密地遵循我所看到的示例。
简而言之，根据您的经验，最好接受这个复杂View需要两个表，然后继续进行。还是认识到现有视图已经提供了视图的“一半”，并且让UI进行了多个查询？
在支持支持不同维度数据的更复杂的UI方面，我正在努力为查询建模和读取模型。想象一个场景，我有一个OrderDetailView，用于...
您在用户界面中使用的模型不一定与您的存储方式相同。我将为您拥有的每个屏幕创建一个单独的ViewModel。