Deployment roznych wersji serwisu .NET MVC

0

Witam,

Chciałbym moc publikować rozne wersje mojego systemu.

zalozmy ze mam 3 wersje (basic, standard i pro)

i np. publikując wersje basic nie chciałbym żeby skompilowaly się klasy i cala dodatkowa czesc serwisu z wersji standard i pro.

to samo gdy chciałbym skompilować wersje standard, nie chciałbym service'ow, managerow całej tej logiki z wersji pro.

jak to najlepiej ustawić??

czy za pomocą conditional deployment.

jtak to zrobic najlepiej, bo tagowanie klas w zaleznosci w jakiej wersji sa mi się nie widzi.

Najlepiej gdyby był jeden plik konfiguracyjny gdzie mam spis klas, czy jak to rozwiazac???

tylko jak kompilatorowi mowic co ma dociagac?

poza tym jak bardzo to musi być rozdzielone, żeby mi się potem nie posypaly jakies zaleznosci.

dzięki za pomoc

0

Podziel na oddzielne projekty (w sensie csproj) i dodaj konfiguracje kompilacji w solucji (oprócz Debug i Release), które będą zawierały te projekty, których potrzebujesz do odpowiedniej wersji.

0

Ok, czyli dzielenie na projekty.

a co jeśli te funkcjonalności sa nieduze. (np. blog czy galeria) tez robic to w osobny projektach ??

bo już przyznam mam tam pare projektów, osobno entoty, osobno viewmodele. Wiec teraz dla każdej funkcjonalności dodac jeszcze po projekcie??

a co z widokiem?? jak np. wygenerować np. menu z lista dostępnych funkcji ??? enum?? dla każdej wersji inny ???

0

Jeśli projekty to zły pomysł, to zawsze możesz podawać do csc listę plików, które ma skompilować.

Ty na pewno chcesz kompilować tylko część aplikacji? Bo może Tobie chodzi po prostu o zarządzanie dostępem do pewnych funkcji aplikacji?

0

no tak ograniczenie funkcjonalnosci, ale wiadomo ze najbezpieczniejszym ograniczeniem jest nieumieszanie kodu w pliku wynikowym. Dzieki temu nawet jesli kod czasami powedruje do klienta, to nie bedzie on w stanie sobie skorzystac z funkcjonalnosci z wersji wyzszej.

0

No ok, czyli problemem nie jest kompilacja lecz dostarczenie oddzielnych binarek klientowi. Ale i tak najlepiej będzie, jeśli nie dostarczysz tych binarek klientowi w ogóle, więc podtrzymuję swoją poprzednią propozycję.

Z tego, co rozumiem teraz masz tylko podział na warstwy, czyli poziomy: prezentacja, view modele, encje. Musisz też podzielić aplikację w pionie, tzn. dla każdego modułu (blog, galeria, itd.) robisz oddzielne projekty poziome. Wychodzi z tego coś takiego: Blog.Web, Blog.BusinessLogic, Blog.Persistence, Gallery.Web, Gallery.BusinessLogic, Gallery.Persistence. Do tego potrzebujesz zapewne zestawu projektów na funkcje infrastrukturalne i wspólne dla wszystkich modułów.

0
somekind napisał(a):

i dodaj konfiguracje kompilacji w solucji (oprócz Debug i Release)

a co z referencjami wtedy ?? jak to dziala, bo jesli nie skompiluje jakiegos projektu a w drugim mam referencje do niego to sie to posypie. jak tego uniknac???

0

Projekty z jednego modułu mają odpowiednie referencje do siebie oraz do części wspólnej. Nie ma referencji między np. projektami z Bloga i Galerii.

0

No tak, ale jak np. musze pobrac liste artykulow z bloga czy obrazkow z galerii to jak z kontrolera strony glownej wywolam service bloga ktory mi przekaze liste artykulów?

0

Funkcjonalności potrzebne więcej niż jednemu modułowi powinny być w części wspólnej.

0

I jeszcze ostatnie pytanie na ktore odpowiedz zakonczy moje pytanka :)

Jak sobie poradzic w widoku z wystepowaniem roznych modulow, np. przy budowie menu, zrobic jakiegos enuma z lista modulow, czy moge automatycznie wykryc jakie moduly sa zaladowane i widok jes wyswietli oczywiscie za pomoca jakiegos serwisu ktory ta liste wygeneruje. ale czy musze ja statycznie ustalic czy moge ja wygenerowac dynamicznie??

0

To już jak uważasz za stosowne, i ilu zmian w projekcie się spodziwasz. Możesz zrobić tak, żeby każdy moduł definiował jakoś strukturę swojego menu, a główny moduł web ją czytał i dynamicznie budował menu.

1 użytkowników online, w tym zalogowanych: 0, gości: 1