Wzorzec projektowy na opisaną sytuację

Witam
Mam taką sytuację, gdzie mamy:

User - jest klasą abstrakcyjną,
Employee - klasa pochodna dziedzicząca po User,
Administrator - klasa pochodna dziedzicząca po User.

Mam metodę, która zwraca Usera, zależnie od typu danych logowania, wygląda to mniej więcej tak:

public User GetUserData(SqlDataReader reader)
{
       if (reader.GetInt32(4) == (int) PermissionLevel.Employee)
       {
                using (var repo = new RepositoryEmployee())
                {
                    return repo.FindUserByLogin(reader.GetString(0), reader.GetString(1)); // Metoda zwraca obiekt klasy Employee z danymi logowania
                } 
       }
       else if (reader.GetInt32(4) == (int) PermissionLevel.Administrator)
       { 
                 // analogicznie
       }
}
 

Inaczej ujmując zależnie od podanego typu enum, czyli poziomu dostępu zwracam obiekt, który dziedziczy po klasie User, czyli albo Employee albo Administrator - wywołując odpowiedną metodę na repozytorium.Czy istnieje jakiś wzorzec projektowy na taką sytuację ? Pytam ponieważ uczę się zastosowania wzorców projektowych. Myślałem o strategii, ale uznałem to za błędne rozwiązanie mojego

Metoda wytwórcza/factory które zwróci odpowiednie repository implementujące np. IUserRepository (z metodą FindUserByLogin).
Czyli stosujesz polimorfizm, bo raz używasz EmployeeRepository, innym razem AdministratorRepository.

To w temacie odpowiedzi na pytanie.

Inna sprawa że w ogóle twoja koncepcja wydaje mi się dziwna.
Czym różni się Employee od Admin i jak rozszerzają klasę User? Dlaczego nie wystarczy aby User posiadał pole PermissionLevel? Albo rolę, czy listę ról w jakich występuje, które determinują listę uprawnień jakie posiada User?

Dziękuje bardzo. Co do Twojej uwagi, podałem przykładową klasę Admin, tak naprawdę sytuacja jest trochę bardziej skomplikowana. Klasy te na tyle rozszerzają User, że uznałem, iż dobrze jest je rozdzielić. Owszem można by się kłócić czy moje rozwiązanie jest dobre czy nie, ale no taką podjąłem decyzję jakiś czas temu.

Taki wzorzec nazywa się ORM. Każdy sensowny (a nawet te bezsensowne w większości też) ORM pozwala na mapowanie hierarchii klas, a później na pobranie konkretnego obiektu na podstawie warunków wyszukiwania.