Migracja aplikacji z .NET na java/spring

0

Czy przepisanie aplikacji (nie duzej) ktora zostala napisana w .NET na java/spring to cos duzego?:)

1
stanley123 napisał(a):

Czy przepisanie aplikacji (nie duzej) ktora zostala napisana w .NET na java/spring to cos duzego?:)

A w czym ona NAPRAWDĘ jest ?

Jak jest warstwowa backend / frontend to prawie bajka, frontendu nie ruszasz a reimplementuejsz wyraziste i proste endpointy

Jak jest wysoce natywaa dla C# (asxp, webforms) to koszmar, zwłaszcza ze paradygmaty są odmienne, i żadną miare nie odwzorujesz A -> A1, B ->B1, C->C1

Jest kilka ale na dziś superniszoywch technologii javowskich a'la webforms - wzmianka na stronie

0
AnyKtokolwiek napisał(a):

Jak jest wysoce natywaa dla C# (asxp, webforms) to koszmar, zwłaszcza ze paradygmaty są odmienne, i żadną miare nie odwzorujesz A -> A1, B ->B1, C->C1

Nawet w przypadku WebForms może być logika oddzielona od interfejsu. Może być pośredni obiekt, który odbiera zdarzenia, z logiki i wywołuje zdarzenia na interfejsie. A i tak, czynność można rozdzielić na kilka etapów:

  1. Będąc cały czas w C#, przerobić tak, żeby architektura była jak najbardziej podobna do docelowej. W celu dopasowania można zrobić dodatkowe klasy będące odpowiednimi interfejsami.
  2. Po tej przeróbce przetestować projekt.
  3. Przepisać do Java, na tym etapie interfejs może być zupełnie inny, jednak dodatkowe klasy pośredniczące sprawią, ze od strony logiki biznesowej, kontakt z interfejsem będzie podobny
  4. Przetestować aplikację Java
  5. Można dokonać uproszczeń, czyli pozbyć się dodatkowych klas, przerabiając odpowiednio logikę biznesową.
1
stanley123 napisał(a):

Czy przepisanie aplikacji (nie duzej) ktora zostala napisana w .NET na java/spring to cos duzego?:)

Wszystko zależy od wielkości aplikacji.

1
andrzejlisek napisał(a):

Nawet w przypadku WebForms może być logika oddzielona od interfejsu.

Wierzysz w to? , w juniorskim kontekście (spsob zadania pytania mi to mówi), najmniejszy zapach nie wskazuje na wybraną architekturę.
WYDAJE MI SIĘ, ze gdyby to było dobrze "zarchitektyzowane" nie padała by myśl o migracji

(tak, pewnie że może być, w teorii tak)

0

Mi to pachnie że fucha ponad własne możliwości przerosła twórcę. Nie mam nic na poparcie tego odczucia.

0
AnyKtokolwiek napisał(a):
andrzejlisek napisał(a):

Nawet w przypadku WebForms może być logika oddzielona od interfejsu.

Wierzysz w to? , w juniorskim kontekście (spsob zadania pytania mi to mówi), najmniejszy zapach nie wskazuje na wybraną architekturę.
WYDAJE MI SIĘ, ze gdyby to było dobrze "zarchitektyzowane" nie padała by myśl o migracji

(tak, pewnie że może być, w teorii tak)

Trafnie. W dodatku, gdyby pkt 1 i 2 z planu @andrzejlisek powiodłyby się jakimś cudem, to jaki sens mają dalsze punkty?

Poprawianie złego projektu tylko po to, żeby i tak wylądował na śmietniku, to marnowanie roboczogodzin. :)

0
SkrzydlatyWąż napisał(a):

Poprawianie złego projektu tylko po to, żeby i tak wylądował na śmietniku, to marnowanie roboczogodzin. :)

Można zaoszczędzić roboczogodziny na modyfikacjach starego projektu, ale w zamian za zużycie roboczogodzin na uruchomienie nowego projektu w ogóle, bo początkowo interfejs i logika zupełnie do siebie nie pasują i trzeba sprawić tak, żeby w ogóle jakoś pasowały, żeby można było skompilować, uruchomić, potem dopiero można testować i poprawiać. Nie ma nic gorszego niż poprawa projektu, który nawet nie daje się skompilować.

Moim zdaniem, przepisywanie w ciemno przy jednoczesnej zmianie aranżacji niesie znacznie większe ryzyko błędów, bugów niż samo przepisywanie przy podobnej aranżacji starego i nowego projektu.

0
SkrzydlatyWąż napisał(a):

Trafnie. W dodatku, gdyby pkt 1 i 2 z planu @andrzejlisek powiodłyby się jakimś cudem, to jaki sens mają dalsze punkty?

Proces "konwersji" języka zaczyna się dopiero od punktu 3. Punkty 1 i 2 to tylko przygotowanie projektu w celu ułatwienia tej czynności.

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