2

I have to design a software using asp .net core which collects data from various datasources (s. picture below). E.g. DataSource1 and DataSource2 are including product data like attributes. DataSource 3 is including the assets of those products. I thought first of all I will collect the data from each datasource and persists them in own datasource with the defined entity below. I have the advantage later at translating or tranforming the data to use one abstract entity.

My question which pattern should be good for this system? Repository, Pipeline,...?? Could you show me some pseudo code?

What about DI if I use interfaces but should have multiplied instances of datasources?

enter image description here

M. Haider
  • 35
  • 4
  • Does it matter from which data source does an attribute come? E.g. if you have a Product P1 attribute AT2 - it has 2 values. Is one of them more important than the other? or are both relevant? – Bartosz Feb 09 '21 at 17:23
  • Later there will be a configuration with rules from which datasource you have to take which value. E.g. we can say take all attributes of datasource 1 and take attribute 1 from datasource 2 if existing, – M. Haider Feb 10 '21 at 06:05
  • 1
    @MilovanTomašević thank you. Nice examples for design pattern. – M. Haider Apr 23 '21 at 08:29

1 Answers1

0

A pattern (or a set of patterns) should be applied to solve a specific problem/complexity.

I think the pattern the pattern you need here is Facade.
The problem that it will solve is that it will hide the complexity of the 'three data sources' for your client.
Within the Facade you would merge the data into a reasonable entity.

Additionally, you could make use of the Proxy pattern, which could give you the 'cache' functionality for the 'merged' entities, which could solve the second complexity you describe.

I am not sure I understand the idea of persisting these items into a fourth datastore, that might be an overkill - but in any case, that can also be achieved with the proxy class - it's just that the cache would be more permanent - if your domain 'allows' it.

As for Repository (pattern) - well, I believe that it's very likely that any reasonable solution that you apply that will hide the details of your data access will end up to be a an implementation of a Repository.
I wouldn't be too strict about naming the patterns and sticking to sample code in books or articles. Patterns are high level guidelines that can be adjusted to needs.

Dharman
  • 30,962
  • 25
  • 85
  • 135
Bartosz
  • 4,406
  • 7
  • 41
  • 80
  • Thanks Dharman for your detailed answer. I would like to use REST API and microservices. The fourth datastore is just there as a backup if the other two datasources (Datawarehouse) are offline. And I will maybe update the data nightly. I will definitely consider your ideas – M. Haider Feb 10 '21 at 06:37