Unity (dependency injection) i EF w ASP.NET MVC

cześć

Otóż nie rozumiem czegoś pomiędzy Entity Framework a Unity w ASP.NET. W takiej jestem sytuacji:

Mam ci ja taki interfejs:

    public interface IUserRepository
    {
        void AddUser(BankUser user);
        BankUser GetUser(string userName);
        BankUser GetUser(int addressId);
        Address GetUserAddress(string userName);
        void DeleteUser(BankUser user);
        bool ContainsUser(string userName);
        void SaveChanges();
    }

Który implementuje to:

public class BankUserRepository : IUserRepository
    {
        protected OnlineBankContext context = new OnlineBankContext();

        public virtual void AddUser(BankUser user)
        {
            context.Users.Add(user);
            context.SaveChanges();
        }

        public virtual void SaveChanges()
        {
            context.SaveChanges();
        }

        public virtual bool ContainsUser(string userName)
        {
            return (GetUser(userName) != null);
        }

        public virtual BankUser GetUser(string userName)
        {
            return context.Users.Where(u => u.Name == userName).FirstOrDefault();
        }

        public virtual BankUser GetUser(int addressId)
        {
            return context.Users.Where(x => x.Address.Id == addressId).FirstOrDefault();
        }

        public virtual void DeleteUser(BankUser user)
        {
            context.Addresses.Remove(user.Address);
            context.Users.Remove(user);
        }

        public virtual Address GetUserAddress(string userName)
        {
            return context.Users.Where(u => u.Name == userName).Select(x => x.Address).FirstOrDefault();
        }
    }

Taki context:

    public class OnlineBankContext : DbContext
    {
        public DbSet<BankUser> Users { get; set; }
        public DbSet<Address> Addresses { get; set; }
    }

Wszystko dobrze działa ale jak najlepiej teraz zapewnic dostep do encji z tabeli Address? Na razie do adresów sięgam poprzez pobranie encji usera, ale nie podoba mi sie ten sposób i chce zrobić coś mądrzejszego. Pierwszy pomysł to dodanie kolejnego interfejsu IAddressRepository, jego implementacja i heja. Tylko co jeśli mój projekt rozrośnie się do przypuśćmy kilkudziesięciu tabel? Będę musiał mieć kilkadziesiąt interfejsów, kilkadziesiąt implementacji i skonfigurowane to dla Unity? To też mi się nie podoba. Kolejny pomysł to napisać jeden generyczny interfejs dla podstawowych operacji i jedna jego implementacja per jedna tabela. Wszystko wygląda fajnie tylko co z konfiguracją Unity w tym przypadku? Obecnie mam to zrobione w ten sposób:

            container.RegisterType<IUserRepository, BankUserRepository>();

Każdy kontroler, który potrzebuje dostępu do repo, dzięki Unity, w konstruktorze otrzymuje implementację interfejsu IUserRepository w postaci BankUserRepository i reszta mnie nie interesuje. Co się stanie jeśli stworze jeden interfejs i wiele jego implementacji? Jak rozróżnie je w kontrolerach? Skąd Unity ma wiedzieć który kontroler będzie potrzebował której implementacji interfejsu? Proszę o podpowiedź osoby doświadczone w tych technologiach

1. Usuń to pseudorepozytorium i nie twórz żadnych nowych.
2. Nie trzeba będzie ich konfigurować w Unity.
3. Profit.

somekind napisał(a):

1. Usuń to pseudorepozytorium i nie twórz żadnych nowych.
2. Nie trzeba będzie ich konfigurować w Unity.
3. Profit.

A masz jakiś przykład konkretny jak to powinno wyglądać? Bo jak szukam w necie to większość przykładów chyba tak wygląda. Gdzieś na forum tutaj czytałem że Repozytorium i EntityFramework nie ma sensu.

Sprecyzuj może pytanie, bo przykładowa implementacja braku repozytorium wygląda mniej więcej tak:

;)

DbContext można wstrzykiwać do serwisów i na nim operować, a do tego będzie to jeden wpis w konfiguracji dla Unity, a nie wiele.

Tak poza tym: http://commitandrun.pl/2016/05/11/Repozytorium_najbardziej_niepotrzebny_wzorzec_projektowy/