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?
1
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).
It sounds like your domain is split only because the information is in multiple databases. If there is one domain object (Employee) then the domain should expose a single source for Employees, and the multiple data sources should be aggregated to present a single Employee to the rest of the system (including a validation method). I can think of two ways to accomplish this:
1) If multiple services will need to access the data sources, you could have an service in front of each database:
EmployeeInfoService -> EmployeeInfoRepository -> db1
EmployeeRoleService -> EmployeeRoleRepository -> db2
EmployeeService -> depends on EmployeeInfoService and EmployeeRoleService
SomeOtherService -> depends on EmployeeInfoService
SomeOtherServiceTwo -> depends on EmployeeRoleService
2) If the employee entity is the only interested party in the information:
EmployeeRepository -> direct queries to db1 and db2
EmployeeService -> depends on EmployeeRepository
SomeOtherService -> depends on EmployeeService
SomeOtherServiceTwo -> depends on EmployeeService
The multiple databases should only be a concern only at the repository and the storage layer. Revisit the separation of layers if the database storage is impacting the validation service.
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?
Depends on whether you need the same validation from any other project that accesses the same database and model. If so, you could just create an ExternalDb1Project.Domain.MetaData
project to contain metadata and validation.
When not required ever by other projects, because “Active” means a totally different thing to your application than to another application accessing the same database, you could stick it under your project like Project.ExternalDb1Project.MetaData
.