Wiele baz danych do jednej aplikacji

0

Witajcie!
Mam zrealizować zadanie utworzenia klas, które będą odpowiadały za połączenie z bazą danych. Chodzi o to by użytkownik w aplikacji mógł sobie wybrać dowolną bazę. Czy ktoś z was ma może jakieś materiały na ten temat? Może ktoś robił coś podobnego?
Pozdrawiam!

0

Nie wiem czy to jest dobre rozwiązanie, ale ja przeważnie buduje ConnectionString na podstawie tego co wybierze użytkownik

public static class SQL
{
    public static string ConnectionString(string instance, string databaseName, string user, string pass)
    {
        return $@"Data Source={instance};Initial Catalog={databaseName};Persist Security Info=False;User ID={user};Password={pass}";
    }
}

Możesz też zamiast stringów wrzucić tam jakiś obiekt konfiguracji

public static class SQL
{
   public static string ConnectionString(Config c)
   {
       return $@"Data Source={c.Instance};Initial Catalog={c.DatabaseName};Persist Security Info=False;User ID={c.User};Password={c.Password}";
   }
}

Dalej to już sobie chyba dasz radę.

0

Ok, to w sumie dobre rozwiązanie jeśli chodzi o connectionstring. A jak później piszesz klasy do wyciągania danych? Dla każdego typu bazy danych oddzielnie?

0

W jakim sensie dla każdego typu bazy? Czyli użytkownik wybiera dowolną technologię bazodanową czy dowolną bazę danych w jednej i tej samej technologii? To spora różnica

0

Chodzi o dowolną technologię. Własnie taka klasa musi mieć unikatowe metody(abstrakcyjne), po których bazy będą mogły dziedziczyć.
Taka abstrakcja dla wszystkich typów baz by później użytkownik mógł dowolnie je podmienić.(na przykład za pomocą delegatów).

0

Chodzi o to by użytkownik w aplikacji mógł sobie wybrać dowolną bazę.

Z tego co napisałeś w poście nie wynika, że chodzi o technologie. Wyszedłem z założenia, że próbujesz tylko zmieniać bazę w tej samej technologii i jest nim MS SQL. Ja korzystam tylko z tej technologii, więc niestety nic więcej nie jestem w stanie pomóc.

0

Jasne, no faktycznie dosyć nieszczegółowo opisałem problem .

0

Z tego co wnioskuję, to chodzi Ci o ORM https://pl.wikipedia.org/wiki/Mapowanie_obiektowo-relacyjne
Poczytaj sobie na ten temat no i może o Code First http://www.entityframeworktutorial.net/code-first/what-is-code-first.aspx

0

@Deltech:
Nie chodzi mu o ORM, tylko o dynamiczne przełączanie między technologią bazodanową. Chce jedną aplikację, w której użytkownik będzie decydował czy chce się zalogować do MySQL, MS SQL, Postgre, SQLite itp itd. Pozwolić na odpowiednią konfigurację połączenia w danej technologii.

0

Nie chodzi mu o ORM, tylko o dynamiczne przełączanie między technologią bazodanową.

W takim przypadku zastosowanie ORM'a to jedyna słuszna metoda.

0

Masz jakiegoś konkretnego ORM'a na myśli?

0

Entity Framework?

0

Próbowałeś kiedykolwiek połączyć się EF'em do MySQL albo SQLite? Bez odpowiednich .NETowskich providerów nie jesteś w stanie nic zrobić. Z tego co się orientuje, bo jeszcze miesiąc temu próbowałem, to pod Visual Studio 2017 nie ma providera do SQLite, ponieważ Micro$oft coś pozmieniał w IDE i SQLite'y nie potrafią tego wydłubać już chyba z pół roku.

Ostatnio zacząłem używać Dapper. Myślę, że tutaj prędzej będzie jakieś rozwiązanie.
Accessing Mysql using dapper

Dapper has no DB specific implementation details, it works across all .net ado providers including sqlite, sqlce, firebird, oracle, MySQL and SQL Server

Tak jak w przypadku EF, potrzebny jest ADO .NET Provider z każdej z technologii, a z tym różnie bywa.

0

@AdamWox
Jaki problem jest z połączeniem SQLite z EF? lub z jakimkolwiek innym system bazodanowym..
To że czegoś nie potrafisz zrobić nie znaczy że się tego nie da.. :(

Jeżeli chodzi o instalowanie poszczególnych providerów, to chyba dobrze by było żeby ktoś piszący aplikację wiedział na czym owa będzie działała i to zaimplementował..

0

Masz rację. Mój błąd. Błagam o wybaczenie...
SQLite provider in VS2017
System.Data.SQLite

1

Jeśli użycie ORMa nie jest możliwe, powiedzmy dla tego ze nie ma wsparcia dla jakiejś niszowej czy też starej technologi, to jest proste rozwiązanie. Dostarczasz abstrakcję w postaci interfejsu (np.IDataStore) która definiuje kontrakty zapisu i wyciągania danych. Dla każdej wspieranej technologii piszesz implementację. Tutaj nic nie stoi na przeszkodzie aby implementacja korzystała z ORMa, ale to jest już szczegół implementaycjny i kodu korzystającego z abstrakcji to nie interesuje.

0

Super! Wasze odpowiedzi bardzo rozjaśniły mi temat! Zadanie te otrzymałem na praktykach i wydaje mi się, że najbliższym rozwiązaniem tego problemu(najbardziej uniwersalne) będzie podejście @Aventus...
Powiedzcie tylko proszę czy uważacie, że taki interfejs byłby ok?

public interface IDataStore
{
    public Task CreateAsync(string something);

    public Task<T> ReadAsync(string something);

    public Task UpdateAsync<T>(string something);

    public Task DeleteAsync<T>(string something);
}
0

Jesteś blisko, ale czemu metody mają przyjmować stringi? Co te stringi reprezentują? Moim zdaniem metody powinny przyjmować obiekty i parametry do zapytań. Ewentualnie możesz zastosować interfejs generyczny- wtedy klasy implementujące będą musiały sprawdzić typ przekazanego obiektu i na jego podstawie wywołać odpowiednie zapytania. Ten problem raczej nie powinien wystąpić przy zastosowaniu ORMa.

1 użytkowników online, w tym zalogowanych: 0, gości: 1