Przeskakiwanie do architektury N-Tier za pomocą WCF?

Question

Pracuję dla dużej państwowej agencji rządowej, która jest i tad za czasów. Nasze zestawy umiejętności są przestarzałe, a zamrożenie budżetu zapobiega wszelkim szkoleniom lub zatrudnianiu nowych pracowników/konsultantów (zwalnianie pracowników również jest niemożliwe). Projektowanie obiektów biznesowych, wdrażanie wzorców projektowych, tworzenie bibliotek kodów i usług, testowanie jednostek, kontrola kodu źródłowego itp. To wszystko, czego nie znajdziesz tutaj. Jesteśmy tak samo jak 0 w teście Joela, jak to tylko możliwe. Dobra wiadomość jest taka, że ​​możemy tylko stąd wyjść!

Tworzymy aplikacje na pulpicie CRUD (w C++, C# lub Java), które trafiają do bazy danych Oracle bezpośrednio przez połączenie ODBC. Zasadniczo mamy GUI zaśmiecone instrukcjami SQL i patchworkowym kodem. Powiedziano nam, aby przejść do zorientowanej na usługi architektury n-warstwowej, aby uniemożliwić bezpośredni dostęp do bazy danych i usunąć potrzeby klienta Oracle na komputerach użytkowników.

Czy WCF to ścieżka, którą powinniśmy skierować? Zrobiliśmy kilka przeglądarek aplikacji n-warstwowych (takich jak this one) i wydaje się, że są łatwe w implementacji, ale po prostu nie wiemy wystarczająco dużo, aby zrozumieć, czy rozważamy nawet odpowiednie technologie. Korzystanie z wygenerowanych w technologii .NET DataSet wydaje się być miłym rozwiązaniem, które pozwala nam zaoszczędzić miesiąc/lata pracy (w przeciwieństwie do tworzenia nowych obiektów biznesowych od podstaw dla wielu projektów). Czy to podejście w puszkach jest opłacalne w pierwszym etapie?

Answer 1

Niedawno zacząłem korzystać z usług WCF dla mojej warstwy danych w niektórych aplikacjach internetowych i muszę powiedzieć, że jest to frustrujące na początku (pierwszy lub drugi tydzień), ale jest całkowicie warte tego, gdy kod zostanie wdrożony.

Powinieneś najpierw wypróbować go za pomocą małej istniejącej aplikacji, lub być może dowód koncepcji, aby upewnić się, że będzie pasował do twoich potrzeb.

Z opisu środowiska, w którym się znajdujesz, jestem pewien, że niemal natychmiast uzyskasz korzyści.

Answer 2

Ostatnia firma, w której pracowałem, wybrała WCF z niemal dokładnie tego powodu, który opisałeś powyżej. Istnieje wiele dobrej dokumentacji i książek dla WCF, stosunkowo łatwo jest pracować, a WCF obsługuje wiele opcji konfiguracyjnych.

Może pojawić się kilka bólów głowy po rozpoczęciu próby zginania WCF do pracy w sposób, który nie został zaprojektowany specjalnie po wyjęciu z pudełka. Są to na ogół problemy z konfiguracją. Ale takie witryny lub IDesign mogą ci w tym pomóc.

Answer 3

Przede wszystkim, na pewno nie (przepraszam za naciskiem) martwić czasu zaoszczędzisz używając wpisywanych DataSet „s kontra tworzenia własnych obiektów biznesowych. Zazwyczaj nie jest to miejsce, w którym spędzasz większość swojego czasu rozwoju. Wolę korzystać z obiektów biznesowych.

W twojej sytuacji chciałbym najpierw wdrożyć proof-of-concept. Jeden, który rozwiązuje wszystkie problemy, które możesz napotkać. Ten proof-of-concept powinien implementować cały przypadek użycia, zaczynając od klienta, pobierając dane z bazy danych i zwracając je do klienta. Przed kontynuowaniem powinieneś być pewny swojej implementacji.

Następnie o wyborze technologii. WCF jest zdecydowanie dobrym wyborem do komunikacji między aplikacjami klienckimi a warstwą usług. Przypuszczam, że zarówno twoi klienci, jak i twoja warstwa usługowa staną się aplikacjami C#? To sprawia, że ​​rzeczy są dużo łatwiejsze, ponieważ interoperacyjność między różnymi platformami (na przykład Java/C#) nadal nie jest banalna, chociaż powinna działać w większości przypadków.

Answer 4

Spójrz na Entity Framework (ponieważ jest już dostępnych kilka dostawców Oracle) w połączeniu z .NET 3.5 SP1, który umożliwia wbudowaną serializację WCF twoich klas wygenerowanych przez EF.

Oto dobry blog, aby zacząć: http://blogs.msdn.com/dsimmons

Answer 5

CSLA może być dobrym rozwiązaniem dla N-warstwowej aplikacji desktopowych. Obsługuje WCF, ma dużą społeczność programistów i jest dobrze udokumentowany. Jest zorientowany obiektowo.