Entity framework 6 - dwie formy zapytan do kontekstu, która lepsza

Cześć. Zostałem wrzucony do projektu gdzie uzywaja Entity Framework 6. Natknąłem sie tam na dwie postaci pisania zapytan do kontekstu EF. Który sposób jest lepszy i dlaczego? :)

Pierwszy sposób:

public class MyService
   {
       private readonly SchoolEntity _context;

       public MyService()
       {
           _context = new SchoolEntity();
       }

       public async Task<bool> GetSomething()
       {
           var data = await _context.GetSomethingElse();
           return data;
       }
   }

i drugi sposób:

public class MyService2
   {
public async Task<bool> GetSomething()
       {
           using(var context = new SchoolEntity())
           {
               var data = await context.GetSomethingElse();
               return data;
           }
       }

Generalnie chodzi mi o to czy lepiej tworzyc kontekst w konstruktorze czy w kazdej metodzie?

Jak zwykle - to zależy. W drugim przypadku tworzysz DbContext w jakimś scope, wykonujesz akcję i po wyjściu z sekcji using wywoływana jest automatycznie metoda Dispose.Jeśli chcesz robić coś na tym kontekście poza tą metodą musisz przekazywać go przez parametry. W pierwszym przypadku wszystkie instancyjne składowe klasy mogą go używać, ale tam oprócz tworzenia nie zaimplementowałeś nic co obsłuży jego usuwanie.

Jakbym miał wybierać co lepsze to wybrał bym podejście drugie ale osobiście zrobiłbym to trochę inaczej i zrzucił całą odpowiedzialność za zarządzanie czasem życia DbContextu na kontener DI. W ten sposób będziesz mógł używać DbContextu podobnie do tego jak to wygląda w przypadku 1, poza tym że to kontener będzie za ciebie zarządzał czasem życia tego zasobu. A do tego będziesz mógł sobie łatwo mockować DbContext i podstawić do testów (jeśli jest potrzeba) na przykład bazę In-Memory.

Jeśli wybierzesz pierwsze podejście, to serwis (a tak naprawdę repozytorium) robi się stateful. Jeśli w przyszłości zdecydujesz się użyć IoC i skonfigurujesz repo jako singleton, to będziesz mieć bardzo trudne do znalezienia źródło błędów. Serwisy powinny być bezstanowe (za wyjątkiem ich zależności -> DI).
Nie trzeba się bać częstego tworzenia kontekstów, bo EF i tak korzysta z puli połączeń do bazy, czyli utworzenie kontekstu nie oznacza otworzenia nowego połączenia do bazy danych, a usunięcie kontekstu nie oznacza zamknięcia tego połączenia.

Poza tym, jeśli podałeś pełny kod, to ten serwis powinien implementować IDisposable i tak jak pisze @var, powinien zwolnić ten kontekst.
Moje serwisy mają kilka metod do obrabiania danych, więc kontekst jest wrzucony w konstruktorze przez DI.

kalimata napisał(a):

Generalnie chodzi mi o to czy lepiej tworzyc kontekst w konstruktorze czy w kazdej metodzie?

Moim zdaniem lepiej robić tak, żeby się dało testować. Czyli ani jedno ani drugie, zależności powinny przychodzić z zewnątrz.