SPA Hot Towel: Multiple Database Context

Question

I am new to SPA hot template and I am trying to use multiple connection strings (multiple database context). Most examples online use only one as follows

[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);
}

...

What is the best way of implementing something like this where I use a repository, Unit of work and am able to join object from different content?

Answer 1

Let's separate (1) the Repo/Unit-of-Work issue from (2) the multiple-database issue.

Server-side coding practices

What you describe appears only in demos. The server code exists to facilitate the client-development story which is the point of these BreezeJS samples. We made no effort to illustrate proper server side coding practices. In fact, we're often showing bad practices.

We're not ashamed. We want your full attention on the Breeze client. A functional server is all we need and "doing it right" would require more code and distractions that have nothing to do with writing a Breeze client.

For the record, I would NEVER create an EFContextProvider in the controller of a real app. The controller should concentrate on mediating client requests.It should be thin. Repository or UoW classes (and helpers) in separate projects would handle business logic and persistence.

The EFContextProvider itself is production grade and appropriate for most applications that turn Breeze client requests into Entity Framework persistence operations.

Multiple databases

If you do all of the joining on the server, your web api (little "w", little "a") can present a single face to the client and you'll only need one set of metadata to describe a model that persists across multiple databases. That's great for client development and is probably the most productive approach, given that you'll have to validate and coordinate cross-database query and save operations on the server no matter what you do on the client.

There is no escaping the fact that your server will be much more complicated than if you had one model, one DbContext, and one database. Too bad you can't separate the workflows so that you have only one model/context/database per feature area. You'll probably lose the ability to use IQueryable and have to write specific endpoints for each query that your client app requires. Oh well.

I smell a deeper architectural problem. But the real world presents us with stinky situations; we must hold our noses and persevere if we possibly can.

At least you can shield the client by managing the mess entirely on the server. That's what I'd try to do.