I'm working on a project that has its own database call it InternalDb, but also it queries two other databases, call them ExternalDb1 and ExternalDb2. Both ExternalDb1 and ExternalDb2 are actually required by a few other projects. I'm wondering what the best approach for dealing with this is?
Currently, I've just created a project for each of these external databases and then generated Edmx and entities using the entity-framework approach. My thought was that I could then include these projects in any of my solutions that require access to these databases. Also, I don't have any separate business layers. I just have a solution like below:
Project.Domain
ExternalDb1Project.Domain
ExternalDb2Project.Domain
Project.Web
So my Domain projects contain the data access as well as the POCOs generated by Entity Framework and any business logic. But I'm not sure if this is a good approach. For example if I want to do Validation in my Project.Domain on the entities in the InternalDb, it's fine. But if I want to do Validation for entities from either of the ExternalDbs, then I wonder where it should go? To be more specific, I retrieve Employees from ExternalDb1Project.Domain. However, I want to make sure they are Active. Where should this Validation go?
How to architect a project like this at a high level? Also, I want to make sure that I use IoC for my data contexts so I can create Fakes when writing tests. I wonder where the interfaces for these various data contexts would reside?
Best Answer
You could treat them as standalone resources. That is, do what you've done, but continue by exposing the data via a service. So instead of including the project references in client projects, include service references.
Then, whatever validation is required by the data is done in the service, and whatever validation logic is only required in/by the client is done in the client.
It depends on your data/clients/security/volume/connectivity requirements as to what type of service you want to expose (OData/REST/etc).