C# 实体不能由多个上下文跟踪，会干扰N层设计

我有一位同事坚持我使用n层数据访问层和MVVM开发ASP.NETMVC网站

他有Silverlight和WPF方面的背景，我曾尝试创建一个解决方案，但这会造成问题

我创建了DAL和逻辑层（使用泛型）：

Dal-包含封装实体框架的存储库模式。 逻辑-通过层，当前没有要应用的通用逻辑

我仍然使用MVC模式，并将实体框架模型传递给视图，除非需要额外的属性或方法——在这种情况下，我创建了一个视图模型和一个接口来映射两者

n层数据访问层已将实体框架上下文锁定在堆栈底部，我遇到的主要问题是无法在多个上下文上跟踪实体。（{“一个实体对象不能被多个IEntityChangeTracker实例引用。”}）

我最近遇到了一个问题，尽管我尝试使用模型、接口和深度复制，上下文还是出现了这个错误

这里的问题是，这是我将尝试在DAL层中放置一个模型并在实体框架实体和模型之间映射数据的方法

---

我理解潜在的问题：即使您处理了一个上下文，它也不会释放附加到它的实体。有没有办法让这种n轮胎数据访问方法与MVC一起使用？或者我是对的，这永远不会起作用，我应该坚持在控制器方法（或使用依赖注入实现的底层类）中使用实体框架上下文。

这里有很多东西需要解包

如果您正在寻找一个MVVM实现，那么您将希望看到类似knockout.js的东西。或者其他一些将在客户端执行声明性数据绑定的框架。有很多文章可以让你理解这一点

但是，让我们先假设您不会走这条路，并且希望坚持MVC

我将停止向您的视图传递实体。你会给自己带来无尽的悲伤。为每个对应的视图创建视图模型。你使用一个界面似乎有点过分了。您可以将实体/回购的linq查询直接投影到视图模型中。您还可以使用Automapper之类的工具从实体映射到视图模型。在问题中附加一些代码可能会有所帮助。而我的视图模型往往是相当平坦的。我不明白为什么需要在视图中执行实体树的深度复制。后者可以使用局部视图或其他方法获得这些视图。
既然您没有将实体发送到视图中，那么当您发布更新信息时，您将不得不重新设置一个新对象，以便从ef中再次获取要更新的对象。进行更改并保存

对我来说，最简单的实现是最好的。我会将上下文传递给controller方法（最好使用IoC），并在controller操作中查询context directy并直接投影到视图模型中。如果在控制器操作之间有很多共享代码，可以将内容移动到服务中，然后将服务注入控制器，并将上下文注入服务。但我首先要将上下文注入控制器

---

关于第2点，我仅在创建操作中从视图传递到ef。在编辑操作中，我获取ef模型（用作viewmodel）的id，并使用ef获取记录。在视图上使用的其他审核信息（创建、修改、删除和由谁创建）字段是受管理的服务器端点，将使用视图模型。我遇到的问题是，当您执行一些比普通的scaffold MVC项目操作更复杂的操作时。与逻辑和DAL的交互意味着我有额外的数据库记录来验证和处理操作。这些都是在自己的上下文中，它被关闭，实体仍然被连接。选择使用dal和逻辑意味着我有这个问题，并且同意简单使用（上下文）可以解决我的所有问题。是否仍然可以使用逻辑层->dal层-实体框架，并在控制器/服务层上执行多个get、更新和创建的复杂操作，而不会出现“{”一个实体对象不能被IEntityChangeTracker的多个实例引用“}”的问题？您一直提到与dal和逻辑的交互。如果您使用的是EF，那么您使用的是ORM，并且仅与域对象交互。它们“DAL”被抽象到EF内部。您的实体是否有任何业务逻辑，或者您是否在使用贫乏的域模型。