Cześć.
Czy dobrze rozumiem, iż założeniem repozytorium jest to, że w logice aplikacji korzystamy z wydzielonego interfejsu, dzięki czemu zmiany w dostępie do źródła danych nie wymagają ingerencji w kod logiki aplikacji (zmieniamy tylko kod w repo)?
Czy poprawnym będzie stworzenie repozytorium, którego metody opierają się o metody DBSet, a następnie posługiwanie się metodami tego repo w aplikacji?
Dobrze myslisz :) Bedzie ok
Szalony Polityk napisał(a):
Cześć.
Czy dobrze rozumiem, iż założeniem repozytorium jest to, że w logice aplikacji korzystamy z wydzielonego interfejsu, dzięki czemu zmiany w dostępie do źródła danych nie wymagają ingerencji w kod logiki aplikacji (zmieniamy tylko kod w repo)?
To akurat jest efekt, bo założenie jest raczej takie, że logika biznesowa ma operować na obiekcie, który zachowuje się jakby był kolekcją w pamięci.
Czy poprawnym będzie stworzenie repozytorium, którego metody opierają się o metody DBSet, a następnie posługiwanie się metodami tego repo w aplikacji?
Będzie poprawne, jeśli przez aplikację rozumiesz logikę biznesową.
Ja bym się jednak zastanowił nad sensem tego - po co mieszać do tego jakieś archaiczne DBSety? No chyba, że masz już legacy system z zaimplementowanym DAL w postaci DBSetów i jakiś nowy moduł chcesz zaimplementować ładniej.
@somekind:
Korzystam z contextu entity framework. Jakie inne rozwiązanie zasugerowałbyś?
Przepraszam najmocniej, porąbały mi się nazwy: DBSet z DataSet. Po prostu zignoruj. :)