SPA热毛巾：多数据库环境

Question

我是SPA hot模板的新手，我正在尝试使用多个连接字符串（多个数据库上下文）。大多数在线示例只使用以下一个

[BreezeController]
public class MyController : ApiController
{
readonly EFContextProvider<ContextClass> _contextProvider =
new EFContextProvider<ContextClass>();

[HttpGet]
public string Metadata()
{
    return _contextProvider.Metadata();
}


[HttpPost]
public SaveResult SaveChanges(JObject saveBundle)
{
    return _contextProvider.SaveChanges(saveBundle);
}

...

在我使用存储库，工作单元并能够从不同内容加入对象时，实现类似这样的事情的最佳方法是什么？

Answer 1

让我们将（1）Repo / Work-of-Work问题与（2）多数据库问题分开。

服务器端编码实践

您描述的内容仅在演示中出现。存在服务器代码以促进客户端开发故事，这是这些BreezeJS示例的重点。我们没有努力说明正确的服务器端编码实践。事实上，我们经常表现出不好的做法。

我们并不感到羞耻。我们希望您全神贯注于Breeze客户端。功能服务器就是我们所需要的，“正确行事”需要更多的代码和干扰，与编写Breeze客户端无关。

为了记录，我绝不会在真实应用的控制器中创建EFContextProvider。控制器应该专注于调解客户端请求。它应该很薄。单独项目中的存储库或UoW类（和帮助程序）将处理业务逻辑和持久性。

  

EFContextProvider本身是生产等级，适用于将Breeze客户端请求转换为Entity Framework持久性操作的大多数应用程序。

多个数据库

如果您在服务器上进行所有加入，您的web api（小“w”，小“a”）可以向客户端呈现单个面，您只需要一组元数据来描述模型在多个数据库中持续存在。这对于客户端开发来说非常有用，并且可能是最有效的方法，因为无论您在客户端执行什么操作，都必须验证和协调跨数据库查询并在服务器上保存操作。

没有逃避这样一个事实：您的服务器将比拥有一个模型，一个DbContext和一个数据库复杂得多。太糟糕了，您无法分离工作流，因此每个功能区只有一个模型/上下文/数据库。您可能会失去使用IQueryable的能力，并且必须为客户端应用程序所需的每个查询编写特定的端点。哦，好吧。

我闻到了更深层次的建筑问题。但现实世界给我们带来了严峻的形势;如果可能的话，我们必须抓住我们的鼻子并坚持下去。

至少你可以通过完全在服务器上管理混乱来保护客户端。这就是我想要做的。