.net n层应用程序的Web项目中的视图模型应该放在哪里？

假设我们有一个ASP.NET MVC web应用程序，它具有以下层：

• 业务逻辑
• 实体（业务域和数据库POCO）
• 通用（资源、常量）
• 数据访问（数据库EF查询、EDMX EF模型等）
• Web应用程序（MVC Web应用程序）

我们使用的是视图模型方法。当前视图模型放置在实体层中。数据访问查询返回视图模型（由于效率问题，所以我们避免使用mapper）

Web层引用所有其他层。 数据访问引用公共和实体层。 业务逻辑引用实体和公共层，将来还引用数据访问层

有一个想法是将视图模型移动到Web层。为什么？因为它们实际上与特定的技术（MVC）和UI实现相关联。 但我们在这里面临一个问题，因为在这个场景中，数据访问层必须引用Web，Web引用数据访问，所以我们有一个循环依赖性问题

此外，我们还有这样一个场景：视图模型的某些验证需要引用数据访问层。我们将把验证方法保留在视图模型中。目前，我们希望通过将数据库上下文类（位于数据访问层）注入构造函数来查看模型来实现它

---

你知道我们怎样才能避免它吗？将视图模型放在我们的Web层内是个好主意吗？

我不确定如何在Web应用程序中使用

ViewModel

。因为它的数据绑定特性，它比桌面应用程序更难

但是，您的web层直接引用到数据层（或者更确切地说，直接访问）。除非它被用来帮助简化UI而不是业务流程，否则它也破坏了N-tier的用途

---

你需要做的是制作两个不同的模型来保持设计的整洁。视图模型放置在web层，当收到域模型时，它将映射到web层。在这里无法避免映射。

即使使用viewmodel，如何避免映射对象？为什么Web项目必须引用数据访问项目？另外，为什么viewmodels必须引用数据访问项目进行验证？@gerdi通过返回视图模型来避免映射对象。所以EF查询在末尾有“selectnewsomevm{fields=sth}”行。Web引用数据访问，因为DAL公开了在控制器中使用的查询DB的方法。Viewmodels必须已注入对数据访问项目的引用，因为某些验证方法必须检查数据库中的某些内容以验证视图模型（并且我们在视图模型中有验证方法）。您不说明是否正在使用依赖项注入，这听起来像是一个IoC容器。我们不使用DI，因为我们架构的其他一些方面使得它很难实现。我说的是注入，但实际上我们正在创建一个对象，它访问基本控制器中的db（比如我们的工作单元对象）。然后我们在视图模型构造函数中传递引用，以便它可以在其验证方法中使用它。无论如何，国际奥委会不是一个答案，因为我们不能使用它。那将是避免绕圈子的一种方法。但是老实说，我不认为viewmodels在哪个项目中有太多的问题。在默认的asp mvc项目中，它们位于“web”部分。因为VM纯粹是UI层的一个新实体。在web项目中使用视图模型方法而不是模型的目的是避免使用ViewBag并简化视图。使用域模型并不总是适合视图的需要。正如我在这里的另一篇评论中所写，我们决定返回视图模型而不是域模型，以避免映射开销。我知道从建筑学的角度来看，它并不“干净”，但它太慢了。谢谢你的回答，它确保了我在我们的方法中不可能在web项目中拥有视图模型（我想是的，但我的团队不确定）。@Landeeyo，不幸的是。如果您追求性能，就很难保持干净的体系结构，反之亦然。然而，通常映射并不像你想象的那么昂贵。对我们来说，使用AutoMapper做同样的事情需要10倍多的时间。虽然我不确定我们是否犯了错误……您是否尝试过使用传统的代码映射？AFAIK

AutoMapper

使用反射，比传统的代码映射速度慢。@Landeeyo我同意。当代码生成工具在手的时候