如何在没有EF的情况下使用Breeze保存更改？

Question

我正在使用存储库，而我正在努力的一件事就是让事情尽可能地脱钩。所以，如果明天我们从关系数据库转换到其他东西，比如NoSQL和类似的东西，我们就好了，我们只需要改变我们的DAL。

我一直试图找出如何在我的WebAPI控制器中实现SaveChanges方法，而无需使用EFContextProvider。我找到了Breeze NoDb示例，但是此示例使用了存储库中的Breeze ContextProvider。这是困扰我的事情，因为Breeze是一个JS库，所以它是关于我的应用程序的呈现。在这种情况下，使存储库使用Breeze中的组件将耦合DAL和演示文稿，这是我不想做的事情。

再次搜索如何在没有EF的情况下实现SaveChanges我发现this问题，哪里有一个非常好的答案，告诉如何将SaveBundle转换为SaveMap，然后告诉使用它来实现保存逻辑。但是我被困在这个方法中，因为SaveMap的条目只提供了一个Type对象和EntityInfo，所以我看不到如何在我的存储库中使用它。

那么，如何处理SaveChanges而不引用EFContextProvider并且不将存储库与ContextProvider耦合？

Answer 1

您打算从SQL Server切换到NoSQL数据库吗？你为什么不想这样做呢？您多久打算一次切换后备存储？可能不经常，如果有的话。

我发现数据库切换，特别是从SQL到NoSQL的转换是范式的重大转变。在我的一个应用程序中，我经历了从SQL到RavenDb的转换。尽管所有内容都已解耦并且无处不在使用存储库，但我仍然需要重写大部分应用程序存储逻辑。

你想做什么 - 你不需要它。因此，不要为自己努力工作，继续实施功能。

Answer 2

ContextProvider完成将JObject（Json.NET在SaveChanges方法中提供）转换为真实的类型化.NET对象的工作。 ContextProvider为每个实体创建的EntityInfo对象包含实体对象本身，以及从客户端获取的entityAspect属性：EntityState（已添加，已修改或已删除），原始对象所有已更改属性的值，以及任何自动生成的键的临时值。这是您自己保存实体所需的信息。为方便起见，“SaveMap”只是按类型组织它们，但您可以随意操作它们。

如post you referenced中所述，您可以继续使用ContextProvider将JObject转换为实体，然后将这些实体传递到适当的存储库。您的存储库不需要了解有关ContextProvider的任何信息。

Answer 3

Breeze提供了一个NHibernate提供程序，您可以看一下它如何与仍然是.NET服务器的非EF后端进行通信。 ContextProvider是一种使得实现任何.NET提供程序变得更加容易的一种方式，但它绝不是必需的。

对于NoSQL，你应该看一下NodeJs中托管的微风节点提供者和MongoDB样本（这表明ContextProvider显然不是必需的）。

我们还希望在不久的将来有一个用Java编写的Breeze服务器实现，它同样没有“ContextProvider”要求。