MVC w aplikacjach nie-webowych?

Cześć,
Chciałbym zapytać bardziej o dobre nawyki programowania, niż o możliwość czy się da.

Czy programując aplikację windowsową, w zasadzie windows service - który będzie hostował funkcje poprzez WCF, udostępniając niektóre funkcje w intranecie inne w internecie, można zastosować (tzn czy jest poprawne, pod względem dobrych nawyków) model programowania MVC?

Tzn. Nie wiem czy można to nazważ MVC, ale będę komunikował się również z bazą danych. I w Visual studio mam to tak:

• Projekt z biblioteką WCF. Przez WCF będę się też komunikował z bazą, dlatego dodam tutaj item: model bazy danych edmx.
• Projekt z modelem. Tzn z modelami (klasami) różnych projektów.
• Projekt z logiką biznesową.
• Projekt z windows service.

Separacja projektu na składowe mogące być stosunkowo niezależne od siebie zawsze ma sens. Czy twój podział można nazwać MVC nie jestem przekonany. Raczej jest to klasyczna architektura 3-warstwowa. DAL, BL, gdzieś musi być jeszcze jakaś warstwa prezentacji. Czym jest u ciebie model i które warstwy i jak będą się nim posługiwać trudno powiedzieć.

Tzn.. inaczej: Mam dwa projekty: WCF Library z funkcjami WCF oraz Windows Service hostujący te funkcje.

WCF Library:

• Tutaj mam WCF Service (klase i iterface)
• ADO.NET Entity Data Model (edmx) - do komunikacji z bazą. Funkcje WCF będą między innymi zapisywać (finalnie za pomocą Stored procedures) różne rzeczy w bazie.

Windows Service

• Będzie hostował WCF Service w intranecie.
• Ale będzie korzystał również z bazy danych - zapisywał oraz odczytywał.

Teraz chcę się upewnić jak sam Windows Service ma korzystać z bazy danych (tzn - jak POWINIEN, aby zachować jakieś dobre zasady)
Czy poprzez zwykły Data Set? Czy może przez ADO.NET Entity Data Model (edmx) z projektu WCF Library?

W poprzednim projekcie, który współpracował z bazą Oracle, robiłem to za pomocą: Devart.Data.Oracle, czyli selecty, tranzakcie tworzyłem w Visualu i tam je puszczałem. Ale nie wydaje mi się to zbyt dobry rozwiązaniem.

Windows service, to usługa windows, która hostuje zaimplementowany interfejs WCF. Ale po co ma ona łączyć się z bazą. Lub inaczej, czy łączy się ona z tą samą przestrzenią danych co usługi WCF'owe, czy używa tylko bazy jako jakiegoś loga, czy sprawdza jakieś uprawnienia, czy pobiera konfigurację?
Jeśli łączy się z tą samą przestrzenią danych to może warto aby host używał tego samego modelu danych. Z drugiej strony jeśli host jest niezależny od usług WCF to zmiany w modelu danych na potrzeby WCF pociągają zmiany w hoście.
Za mało informacji, aby coś sensowniej powiedzieć.

Usługa łączy się z tą samą bazą danych. Będzie głównie pobierać z bazy danych konfigurację do poprawnego "swojego" działania, pobierać inne dane oraz zapisywać logi, również w tej samej bazie danych.

To że w jednej bazie to mało istotne. Czy host (usługa windows) i usługi (implementacja interfejsu WCF) będą używały tych samych danych? Z tego co napisałeś wynika mi że nie, więc w takiej sytuacji oba elementy mogą być rozłączne i równie dobrze pobierać dane z różnych źródeł. Jeśli tak to wg mnie host nie powinien wręcz korzystać z modelu dla WCF.
A czy host będzie miał własny entity data model (z właściwymi dla siebie tabelkami) to już inna historia.

W zasadzie to host będzie sam "osobiście" wykonywał trochę inne zadania niż udostępniał. Będzie to taki "JobWatcher" - tzn poprzez WCF będzie udostępniał funkcje dodawania nowych zadań do bazy.
Natomiast Host (usługa Windows) będzie sprawdzać w tej samej tablicy czy jakieś Joby są do wykonania.

Aczkolwiek, istnieje dość spore prawdopodobieństwo, że kilka funkcji mogą się powielić - możliwe że funkcje odczytywania z bazy jakiś danych informacyjnych.

Pomimo faktu, iż jakaś część funkcjonalności powtórzy się w obu modelach bazy, należy stworzyć dwa, po jednym w każdym projekcie?