可以从存储库返回 Viewmodel 吗？
在这里呆了一段时间，但这是我的第一个问题@所以。
场景： Mvc 站点。大多数页面的视图模型。 每个视图模型都包含从不同存储库获取的模型或 iqueryables。
每个源都会经常更新（从站点的独家范围之外），因此即使在本地缓存，也会需要大量的数据源锤击。
我们面临的问题是，当使用多个存储库创建视图模型时，每个存储库都会触发到数据源的连接/获取（如果需要重新填充）。
通过从存储库返回完整的视图模型可以轻松避免这种情况。然后，存储库可以使用单个连接（在大多数情况下，甚至只有一个 SQL 存储过程）来获取所有需要的数据。
有人提到视图模型不应该参与存储库。我实际上没有看到这有任何问题，所以我的问题是可能会产生什么影响？
Been around here for a while but this is my first question @ so.
Scenario:
Mvc site. Viewmodels for most pages.
Each viewmodel contains models or iqueryables acquired from different repositories.
Each source is updated frequently (from outside the scoop of the site) so even if caching local it will be a lot of datasource hammering.
The problem we're facing is that when a viewmodel is created using more then one repository each of them trigger a connection/fetch to the datasource (if they need to repopulate).
This could easily be avoided by returning a complete viewmodel from the repository. Then the repository could use a single connection (in most cases even with only one sql stored procedure) to fetch all needed data.
Someone mentioned that viewmodels should not be involved in repositories. I don't actually see any problems with this so my question is what could be the impact?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 MVC 没有硬性规定 - 您应该始终执行适合您的特定场景的操作。从存储库层返回完整的视图模型是不寻常的，但如果填充它是一组特别数据库密集的操作，可以简化为单个存储过程，那么为什么不呢。
检索视图数据的方法总是有可能重复您在其他地方的代码，因此与 DRY 相矛盾，从而导致以后出现潜在的维护问题。
如果您发现检索单个页面所需的所有数据需要多次调用多个不同的存储库，这表明您的存储库可能没有充分建模来满足您的要求，这可能是一个更好的地方来考虑减少存储库的数量。数据库连接/获取。
With MVC there are no hard and fast rules - you should always do whatever fits in with your particular scenario. It is unusual to return complete view models from the repository layer, but if populating it is a particularly database intensive set of actions that could be simplified into a single stored procedure then why not.
There is always a potential that the method for retrieving the view data is repeating code that you have elsewhere, and therefore contradicting DRY leading to potential maintenance issues later.
If you find that retrieving all the data that you need for a single page requires multiple calls to multiple different repositories this suggests that your repositories are perhaps not modelled sufficiently to meet your requirements and this may be a better place to look at reducing the number of database connections/fetches.