Czy przepisanie aplikacji (nie duzej) ktora zostala napisana w .NET na java/spring to cos duzego?:)
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
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:
- 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.
- Po tej przeróbce przetestować projekt.
- 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
- Przetestować aplikację Java
- Można dokonać uproszczeń, czyli pozbyć się dodatkowych klas, przerabiając odpowiednio logikę biznesową.
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.
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)
Mi to pachnie że fucha ponad własne możliwości przerosła twórcę. Nie mam nic na poparcie tego odczucia.
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. :)
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.
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.