Architecting multi-model multi-DB ASP.NET MVC solution

Question

I have an ASP.NET MVC 4 solution that I'm putting together, leveraging IoC and the repository pattern using Entity Framework 5. I have a new requirement to be able to pull data from a second database (from another internal application) which I don't have control over.

There is no API available unfortunately for the second application and the general pattern at my place of work is to go direct to the database.

I want to maintain a consistent approach to modeling the domain and use entity framework to pull the data out, so thus far I have used Entity Framework's database first approach to generate a domain model and database context over the top of this.

However, I've become a little stuck on how to include the second domain model in the application.

I have a generic repository which I've now moved out to a common DataAccess project, but short of creating two distinct wrappers for the generic repository (so each can identify with a specific database context), I'm struggling to see how I can elegantly include multiple models?

Answer 1

When talking to an external system you are building an integration. When you integrate with someone, this someone does not become part of your domain model.

As you mentioned, you have no control of that other database. If one day they change something in their tables, your whole application will become unusable and there will be very little you can do except changing your application.

What integration normally assumes and you mentined that too is an API. If you have no API you have build your own. Create a separate service that will read from that database and give it to your main application via an API. Every communication that occurs between your system an external system can be divided to messages (one or two way) and on-demand data requests. For messages you can use a bus like MassTransit or NServiceBus and you build your own module, in vase of NServiceBus it would be a satellite, to transfer messages to and from the external database. If this is on-demand data requests, you can build your own web service that will read from that external database and provide it to your external system for reading via web service calls.

How you work with external database within the adapter is your own choice. You can use EF if you like. If they change their table you will just change your adapter.

Plus, this adapter approach (in fact this is a design pattern) you can easily switch when they come up with a proper API one day or may be any other method like exchanging XML files or similar.

And one last comment - the fact that you created a model in EF designer by clicking "read from database" button or how it called does not mean you got a domain model. You just got some classes that mapped to some tables. Some call it "domain model" but believe me, it is not.

Answer 2

I think at some point you are going to have to write two adapters. Interfaces are a great way to tie things together, but each model needs to access its own data.

I think you are on the rigjt path by seperating out the data access. If you have both models interact through an interface, adding more models in the future will be easier.

What objects knows the context on the information being saved? I can see where you could have a couple of objects som type of SQL statement object to write to the database. Even then you still need to translate to/from the domain models.

Good luck.

Answer 3

Taking a step back from your actual question, you could be in for a whole world of pain if the rug is pulled from under you by the other project changing it's schema.

You acknowledge the other system does not have an API for you to use. I would push for this to be created.

The other project may not be be in an active workstream, have budget etc, so maybe your project will have to pay for it in some fashion, and maybe even you have to do the work.