Witam,
Chcę utworzyć prostą aplikację serwerową (console app, albo windows service), która będzie udostępniać WCF a niektóre dane zapisywać do bazy danych. Na serwerze będzie oczywiście baza danych (nieistotne jaki silnik). Wszystko napisane w C#.
Czy Entity Framework jest dobre do stosowania po stronie serwera? Większość przykładów pokazuje EF w aplikacja klienckich, jak na stronach w ASP.NET czy aplikacjach WPF, dlatego nie jestem pewny czy to najlepszy sposób.
Pozdrawiam,
EF to ORM służy do względnie łatwego łączenia aplikacji z bazą danych. Wszystko jedno jakiej aplikacji - ważne jest, że ją łączysz z bazą. A "strona ASP.NET" to przecież jest aplikacja serwerowa, tak samo jak i WCF.
Ogólnie tak. Miej tylko świadomość że jeśli zamierzasz przetwarzać(dodawać lub robić update) duże ilości danych (rzędu >100tyś rekordów/ przetwarzanie) to wydajnościowo okazuje się to niestety słabe i warto szukać czegoś innego (nawet wrócić do czystego SQL).
Jeśli mają to być proste operacje typu - pobierz fakturę o ID , albo zrób Update itd. to wydajnościowo nie ma się czym przejmować.
Bardziej niż czy jest to możliwe, chodziło mi o to czy ogólnie stosuje się EF w aplikacjach czysto serwerowych. Np. usłudze windows. Czy jest to praktykowane "w produkcji"? Czy tak jak W2K napisał przeważnie wykorzystuje się czyste SQL z jakąś powłoką abstrakcyjną jak Repository pattern?
Moja aplikacja nie będzie miała dużo zapytań do bazy, to bardziej taki projekt do nauki poza pracą.
PS. Chyba więc najlepiej byłoby zaimplementować jeszcze jedną warstwę abstrakcyjną nad EF? Np. Repository pattern, tak, że gdybym miał się pozbyć EF6 nie musiałbym ruszać właściwego kodu.
mnd017 napisał(a):
Bardziej niż czy jest to możliwe, chodziło mi o to czy ogólnie stosuje się EF w aplikacjach czysto serwerowych. Np. usłudze windows. Czy jest to praktykowane "w produkcji"? Czy tak jak W2K napisał przeważnie wykorzystuje się czyste SQL z jakąś powłoką abstrakcyjną jak Repository pattern?
Generalnie EF jest niestety szeroko stosowany do obsługi baz danych. Nie korzystanie z ORMów to strata czasu, na którą większość firm nie może sobie pozwolić. W ADO.NET/procedurach składowanych pisze się co najwyżej jakieś krytyczne elementy, których EF nie potrafi zrobić.
No chyba, że mówimy o jakichś JanuszSoftach, w których ludzie koncepcji ORMów nie ogarniają - tam nie ma nawet EF.
PS. Chyba więc najlepiej byłoby zaimplementować jeszcze jedną warstwę abstrakcyjną nad EF? Np. Repository pattern, tak, że gdybym miał się pozbyć EF6 nie musiałbym ruszać właściwego kodu.
Tworzysz aplikację zgodnie z DDD? Repozytoria służą do dostarczenia metod służących do operowania na kolekcji obiektów danego typu, i oddzielenia logiki biznesowej od źródła danych, nie do tego, aby móc sobie wymienić ORMa. Szanse na to są nikłe, a tworzenie zbędnej warstwy abstrakcji to generalnie strata czasu.
mnd017 napisał(a):
Czy tak jak W2K napisał przeważnie wykorzystuje się czyste SQL z jakąś powłoką abstrakcyjną jak Repository pattern
Chyba tego jednak nie napisałem ;-)
Generalnie to EF stosuje się na produkcji nawet po stronie serwera bo jest bardzo wygodny w wielu miejscach. Są też miejsca tak jak napisał Somekind gdzie ze względu na krytyczną wydajność dla procesu stosować sie go nie powinno (podam przykład - u mnie w firmie zamiana zasilenia za pomocą XMLi przetwarzanych na zapytania za pomocą EF na zasilenie za pomocą SQL Server Integration Services pozwoliła skrócić czas operacji z 10-14h na 0,5h-1h). Takiej miejsca musisz zdefiniować sam i wybrać optymalne rozwiązanie. Jeśli po prstu przepychasz dane z jednej tabeli do drugiej bez logiki biznesowej to EF będzie mało optymalny, natomiast gdy logiki jest dużo to zysk wynikający z zastosowania np. czystego sql będzie niewspółmierny do wygody i dodatkowego nakładu pracy. Inne małe operacje typu pobranie(a szczególnie przy bardzo złożonych warunkach), update itd są wprost idelane żeby robić je za pomocą EF, tu różnica a wydajności też będzie znikoma.
somekind napisał(a):
Tworzysz aplikację zgodnie z DDD? Repozytoria służą do dostarczenia metod służących do operowania na kolekcji obiektów danego typu, i oddzielenia logiki biznesowej od źródła danych, nie do tego, aby móc sobie wymienić ORMa.
Tak, dokładnie staram się trzymać standardów DDD. To kiedy powinno się stosować Repository Pattern? Przecież i stosowanie repozytoriów i ORM oddziela warstwę biznesową od źródła danych?
Moja baza nie będzie miała dużo liczenia. Gra w szachy. Baza to będzie baza użytkowników + historia ich gry, kroków. Więc będą to niegroźne zapytania. Ale tak jak pisałem (chyba), piszę tą grę w celach edukacyjnych, dlatego interesuje mnie wiele wariantów a nie tylko "w twoim przypadku, użyj tego i zapomnij. będzie działać". Nigdy nie pracowałem po stronie serwera, w pracy zajmuję się tylko Frontendem, korzystamy z serwisów i nie mamy pojęcią co jest "za kurtyną". Dlatego ciekawi mnie jak to jest w praktyce. Czy faktycznie EF albo NHibernate jest tak popularne w aplikacjach serwerowych. Bo np. w wielu wymaganiach o prace są wylistowane.
mnd017 napisał(a):
To kiedy powinno się stosować Repository Pattern?
Generalnie wtedy, i tylko wtedy, gdy masz DDD i naprawdę tego DDD potrzebujesz.
Przy czym większość aplikacji nie potrzebuje DDD (a przynajmniej nie całość aplikacji), i większość aplikacji nie powstaje zgodnie z DDD - nawet jeśli ich twórcy tak twierdzą.
Przecież i stosowanie repozytoriów i ORM oddziela warstwę biznesową od źródła danych?
No nie do końca. Repozytoria oddzielają ją logicznie - to abstrakcja na potrzeby logiki biznesowej, biznesowo zdefiniowane API do operowania na kolekcjach encji (a konkretnie aggregation rootów). W repozytorium i tak potrzebujesz czegoś, co będzie operowało na bazie danych - może to być ORM, może to być biblioteka oparta o inny wzorzec, a może to być wywoływanie poleceń SQL i parsowanie ich wyników.
Sam ORM zaś nie tyle oddziela, co łączy świat obiektowy z bazą danych. Nie jest jedynym rozwiązaniem, ale w 99% przypadków jest najwygodniejszy do użycia przez programistę, bo znacznie przyspiesza czas tworzenia aplikacji.
Moja baza nie będzie miała dużo liczenia. Gra w szachy. Baza to będzie baza użytkowników + historia ich gry, kroków. Więc będą to niegroźne zapytania. Ale tak jak pisałem (chyba), piszę tą grę w celach edukacyjnych, dlatego interesuje mnie wiele wariantów a nie tylko "w twoim przypadku, użyj tego i zapomnij. będzie działać".
Skoro to o cel edukacyjny chodzi, to napisz raz z użyciem ORMa, a raz bez i porównaj czas, który na to poświęciłeś. :)
Czy faktycznie EF albo NHibernate jest tak popularne w aplikacjach serwerowych. Bo np. w wielu wymaganiach o prace są wylistowane.
Tak, są. Przy czym EF jest jakieś 20 razy popularniejsze od NH.
ORMów nie używają tylko: