Myślę, że opcja 2 nie jest zła, ale może nie być potrzebna. Mikrousługi umożliwiają zaspokojenie potrzeb wielu aplikacji.
Dużym czynnikiem tutaj jest to, czy istnieje jakaś różnica między tymi dwoma schematami i czy kiedykolwiek będzie w przyszłości.
Zazwyczaj myślę, że używanie interfejsów do repozytoriów jest niepotrzebne; jednak w tym przypadku może być to warte wysiłku. Fabryki repozytoriów będą dla Ciebie ważne.
Mój problem z opcją 1 polega na tym, że jest ona zbyt specyficzna. Powinieneś być w stanie przejść od konfiguracji, którą opisałeś, do dwóch oddzielnych instancji, z których każda wskazuje na swoją własną bazę danych. Aplikacja NIE powinna troszczyć się o to, skąd pochodzi jej dane.
Chociaż schemat nie różni się dla dwóch różnych baz danych, możesz mieć jedno repozytorium z łatwością sobie z nimi radzić, bez różnicy między aplikacją:
public class MyEntityRepository : ISavesMyEntity, IGetsMyEntity
{
public MyEntityRepository(string connectionString)
{
_connectionString = connectionString;
}
}
public class MyEntitySaverFactory
{
public ISavesMyEntity GetSaver(User user)
{
if (user.IsUK)
return new MyEntityRepository(Config.Get("UKConnString"));
if (user.IsUS)
return new MyEntityRepository(Config.Get("USConnString"));
throw new NotImplementedException();
}
}
//USE
ISavesMyEntity saver = factory.GetSaver(currentUser);
saver.Save(myEntityInstance);
Jeśli schematy DB kiedykolwiek staną się rozbieżne między USA a Wielką Brytanią, wówczas podzielisz tę funkcjonalność na dwa całkowicie różne repozytoria. Byłoby to łatwe, ponieważ wszystko, co musisz zrobić, to zmienić fabrykę.