Czy powinienem używać obiektów Entity Framework, DataSet lub Custom?

Question

Naprawdę ciężko mi tu jest. Muszę zaprojektować "aplikację na komputer", która będzie używać WCF jako kanału komunikacji. Jest to wielopoziomowa aplikacja (baza danych i serwer aplikacji są takie same, klient przechodzi przez chmurę internetową).

Aplikacja jest trochę skomplikowana (pod względem SQL i logiki kodu), a następnie zwykłych aplikacji LOB, ale koncepcja jest taka sama: Odczyt z DB, aktualizacja do DB, obsługiwać współbieżność itp. Mój problem polega na tym, że teraz z Entity Framework jest otwarty, nie mogę zdecydować, w jaki sposób kontynuować: powinienem używać Entity Framework, Dataset lub Custom Classes.

Jak rozumiem przez Entity Framework, utworzy mapowanie obiektów dla moich tabel DB WRAZ Z skryptami CRUD. To wszystko dobrze i dobrze dla prostego CRUD, ale w większości przypadków "Wybór" jest złożony i wymaga niestandardowego SQL. Rozumiem, że mogę używać zapisanych procedur w EF (nie lubię SP btw, nie wiem dlaczego, lubię kodować mój SQL w DAL ręcznie, czuję się bezpieczniej i wygodniej w ten sposób).

Korzystając z DataSet, będę używał moich własnych instrukcji SQL i zapełniam zestaw danych. W klasach niestandardowych (obiekty dla tabel DB) zapełniam moje niestandardowe instrukcje SQL w tych niestandardowych klasach (kolekcje i listy itp.). Chcę używać EF, ale nie mam pewności, wdrażanie aplikacji, których SQL nie napisałem i nie widzę w kodzie. Czy coś mi umyka.

Każda pomoc w tym zakresie byłaby bardzo doceniana.

Xeshu

Answer 1

Zgodziłbym się z Markiem G. 100% - ssanie DataSet, szczególnie w scenariuszu WCF (zwiększają one koszty związane z manipulowaniem danymi w pamięci) - nie używaj ich. Są w porządku dla początkujących i dwupoziomowych aplikacji komputerowych na małą skalę - ale nie użyłbym ich w poważnej, profesjonalnej aplikacji.

Zasadniczo, twoje pytanie sprowadza się do tego, jak przekształcić swoje wiersze z bazy danych w coś, co można zdalnie w WCF. Oznacza to jakąś formę mapowania - albo robisz to sam, używając DataReaderów, a następnie przepychasz wszystkie dane do klas WCF [DataContract] - możesz to zrobić, dajesz pełną kontrolę, ale jest też nudny, uciążliwy i podatny na błędy.

Albo pozwalasz, aby jakiś gotowy ORM obsłużył tę pracę dla ciebie - wybierz spośród Linq-SQL (świetny, łatwy w obsłudze, elastyczny, ale tylko SQL Server), EF v4 (przez Marzec 2010 - wygląda bardzo obiecująco, bardzo elastycznie) lub jakikolwiek inny ORM, naprawdę - cokolwiek najlepiej pasuje do twoich potrzeb.

Innymi poważnymi konkurentami w przestrzeni ORM mogą być Subsonic 3.0 i NHibernate (spośród wielu innych).

Więc Podsumowując:

• zapomnieć o zbiorów danych
• albo masz 100% kontroli i mapowanie między SQL i obiektami siebie
• niech jakiś zdolny obsłużyć że ORM (Linq- to-SQL, EF v4, Subsonic, NHibernate i inni) - które naprawdę nie mają większego znaczenia, tzn. to także kwestia osobistych preferencji i stylu kodowania.

Answer 2

Nie mogę popierać zestawów danych, szczególnie w środowisku SOA jak WCF - będzie to działać, ale dla większości z niewłaściwych powodów. Po prostu nie są przenośne, a IMO tak naprawdę "nie działa" ponad granice usług. Oczywiście, IMO nie działają w większości innych scenariuszy ;-p

Tak więc to sprowadza się do tego, ile rur hydraulicznych chcesz wykonać. Większość ORMów stworzy dla Ciebie typy serializujące WCF; osobiście W tym momencie użyłbym LINQ-SQL; jest prostszy i bardziej kompletny niż EF, chociaż EF 4.0 ma być znacznie lepszy niż EF w 3.5sp1. Możesz użyć niestandardowego TSQL (poprzez ExecuteQuery, który nadal odwzorowuje z powrotem do obiektów), ale zwykle używam SPROC (dla złożonych zapytań) lub zapytań generowanych przez LINQ (dla prostych żądań).

Pisanie typów również jest w porządku i będzie działać z NHibernate itp. Tak wiele opcji.

Answer 3

Podczas gdy EF działa z WCF, a więc bardzo obiecujące, powinieneś rozważyć wysiłek, aby przyspieszyć wraz z nim. Zwłaszcza gdy robimy jakieś nie trywialne rzeczy, projektant w VS2008 nie może już otworzyć modelu i musisz kodować swój model w xml.

Należy również pamiętać, że EF działa na bardzo wysokim poziomie abstrakcji. Z powodu law of leaky abstractions nie jest to wszystko tak błyszczące, jak powinno być :) W drugą stronę oznacza to, że musisz radzić sobie z bardzo szalonymi i trudnymi do odczytania instrukcjami sql wysłanymi do twojej bazy danych, jeśli chodzi o rozwiązywanie problemów/problemy z wydajnością.