/ / Jakiej struktury projektu używasz w aplikacjach C # obsługujących wiele usług WCF? - c #, visual-studio-2008, wcf

Jakiej struktury projektu używasz w aplikacjach C # obsługujących wiele usług WCF? - c #, visual-studio-2008, wcf

Potrzebuję aplikacji C # WinForms do obsługi wielu usług WCF. Który z nich (1 lub 2) byłby odpowiedni?

  1. Czy powinienem utworzyć projekt C # WinForms i inny projekt biblioteki usług WCF?

  2. Lub po prostu utwórz formularz w projekcie WCF ServiceLib? - Czy nadal będę w stanie zrobić to wszystko:

    • kontrolować żywotność usługi, ustaw właściwości usługi
    • otwórz usługę (i ustaw ją w trybie nasłuchiwania)
    • zamknij usługę

Odpowiedzi:

1 dla odpowiedzi № 1

Liczba projektów do utworzenia

Nie ma problemu z zrobieniem tego wszystkiego w jednym projekcie. W rzeczywistości, jeśli aplikacja WinForms hostuje same usługi, wygodniej jest to zrobić w jednym projekcie, ponieważ masz tylko jeden plik .exe.

Z drugiej strony, jeśli wdrażaszoddzielny kod klienta i serwera, wygodne może być posiadanie interfejsu usługi (lub całej usługi) w osobnej bibliotece dll. W ten sposób zarówno klient, jak i serwer mogą odwoływać się do tej samej biblioteki DLL.

To naprawdę architektoniczna decyzja oparta na szerszym obrazie tego, co próbujesz zrobić. Dla prostego exe WinForms, który obsługuje kilka usług, na ogół użyłbym tylko jednego projektu.

Co można zrobić w projekcie WCF ServiceLib

Generowany jest domyślny projekt biblioteki usług WCF.dll, więc musisz go zmienić, aby utworzyć plik .exe, jeśli chcesz go uruchomić i wyświetlić WinForms. W swoim pliku .exe możesz zrobić wszystko na liście. W szczególności w uruchomionej aplikacji możesz:

  • zmień konfigurację usługi
  • kontrolować, czy usługa jest aktywna, czy nie
  • uruchomić i zatrzymać usługę

Możesz także połączyć się z własną usługą w celu przetestowania.


2 dla odpowiedzi nr 2

Lubię rozdzielać moje projekty WCF w następujący sposób:

  • biblioteka klas z kontrakty - wszystkie umowy serwisowe, umowy danych itp. Jeśli Twoje rozwiązanie staje się duże, może to być nawet kilka bibliotek klas, z których każda obsługuje jeden obszar / temat rozwiązania
  • biblioteka klas z wdrożenie usługi - znowu, jeśli masz wiele usług, może nawet wybierzesz kilka bibliotek klas
  • aplikacja Winforms lub konsola jako usługodawca - do celów testowania i debugowania

  • biblioteka klas dla proxy klienta / proxy - ponownie, jeśli ma to sens, może to być nawet kilka bibliotek - jedna dla każdego „podsystemu logicznego”

  • i wreszcie twój faktyczny klient - Winforms, WPF, dowolna aplikacja, która faktycznie zużywa i używa serwerów proxy klienta

Powodem tego jest to, że chcę miećwyraźny podział obaw - ponieważ usługi nie mają nic oprócz umów (usług i danych), które należą do osobnego zestawu. Ponieważ usługodawca naprawdę nie ma nic wspólnego z wdrożeniem usługi, te dwa powinny również zostać rozdzielone.

W Twoim przypadku aplikacja (lub aplikacje) Winforms byłyby rzeczywistymi hostami usług - np. twoja instancja a ServiceHost klasy w aplikacji Winforms i hostuj w niej odpowiednią usługę (z zestawu usług) ServiceHost - i oczywiście możesz mieć tyle hostów usług, ile potrzebujesz! (jedna na usługę, którą musisz udostępnić)

Po stronie klienta opłaca się umieszczać serwery proxy w osobnym zestawie, ponieważ zestaw ten może być teraz współużytkowany przez kilka projektów klienckich, a kod ma tylko jedna lokalizacja.

A skoro mam umowy osobnoasembler, pod warunkiem, że kontroluję oba końce komunikacji .NET-do -NET .

Wiele z tych rzeczy pochodzi od doskonałości Miguela Castro Extreme WCF screencast - zdecydowanie wart obejrzenia! (to samo dotyczy Keitha Eldera) Demystifying WCF - także doskonałe rzeczy!)