Wpis z mikrobloga

Wyszło w projekcie takie założenie, żeby zrobić jeden kontroler przyjmujacy argumenty i nazwy funkcji i pisać funkcje na bazie danych w mssql (takie wymagania co do bazy u klienta ;) bez hejtu.). Dzięki temu raz napisaliśmy kontroler i teraz bez zmiany serwera mozemy dokładać nowe funkcjonalności. Serwer przerabia wszystko z bazy danych na json {nazwazwracanejkolumny : wartosc ...}. Co myślicie o takim podejściu, ja jestem tak średnio do tego nastawiony. Dodatkowo używamy różnych metodHTTP ( GET , POST itp) poprzez prefixy w nazwach funkcji ( np. funkcja dodawania danych nazywa się POSTjakiesdanecostam(). Nie mam dużego doświadczenia bo w #programowanie zawodowo siedzę 2 lata, ale #spring i webservice jestem dość początkujący. To pierwszy taki mój projekt. Czekam na wypowiedzi bardziej doświadczonych :)

#java #rest #programowanie
  • 45
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@Kaczus2B: No właśnie o to mi chodzi, nigdzie nie napisałem, że zapytania mają być na sztywno gdzieś zapisane. Cały czas piszę o warstwie abstrakcji nad bazą danych, która jest odpowiedzialna za komunikację z konkretnym silnikiem bazy danych i udostępniającą interfejs dla klientów.

@Pipcieo: > Przejście z .NET na Javę oznacza całkowite przepisanie aplikacji - od zera
Miałem tu na myśli, że logikę można udostępniać jako usługę, wtedy wystarczy
  • Odpowiedz
@Pipcieo: O operacjach stricte biznesowych. Na przykład wyliczanie rabatu nie musi być zaszyte wewnątrz aplikacji, tylko w zewnętrznej usłudze z którą aplikacja kliencka będzie się komunikować. Wtedy zmiana UI nie narusza w żaden sposób logiki biznesowej systemu i jest łatwa do realizacji bez potrzeby przepisywania całej logiki.
  • Odpowiedz
@Pipcieo: jw logika biznesowa i tak powinna być odseparowana, bo jak potrzebujesz dopisać drugą aplikację nawet w tym samym języku to przecież nie będziesz copypastować kodu, bo się zakopiesz przy utrzymaniu.
  • Odpowiedz
@markaron: napisałeś, że klient chce zmienić Oracle na MS SQL. Ja odpisałem, co jeśli Oracle ma zostać, ale on chce Javę a nie .NET. A ty mi o UI i usługach.

@dixx mówimy o zmianie technologii, a nie o separowaniu logiki biznesowej.
  • Odpowiedz
@Pipcieo: Ale co to ma do rzeczy? Jeżeli aplikacja kliencka jest w .NET ale logika biznesowa znajduje się poza nią (np. w dedykowanych usługach/usłudze) to nie ma problemu, żeby przejść z .NET na Jave, czy z MS SQL na Oracle bez dodykania logiki biznesowej
  • Odpowiedz
@markaron: to jeszcze zależy jaka aplikacja, bo jak w modelu saas to ok, ale powiedzmy, że logika biznesowa musi być u klienta, a on ma życzenie trzymania wszystkiego na jbosie, a nie serwerach microsoftowych-to w sumie równie uzasadnione, co żądanie MS Sqla zamiast Oracle
  • Odpowiedz
@Pipcieo: No to zależy jak jest zaprojektowany podział odpowiedzialności w aplikacji. Jeżeli wszystko jest zamknięte w dll to lipa, jeżeli ktoś myślał przed tworzeniem, to da się to rozwiązać w miarę bezboleśnie.

@dixx: no tak, ja mówię o sposobach w jaki można to rozwiązać, i krokach jakie należałoby podjąć, aby takie zmiany były w miarę bezbolesne, ale wiadomo, że jeżeli klient się uprze na jbossa i hostowanie całego
  • Odpowiedz
@markaron: nie da się tego zrobić bez przepisania kodu, amen. Poziom bólu zależy od poziomu dwujęzyczności ekipy przepisującej i jakości dokumentacji projektu. Zupełnie jak przy migrowaniu z Oracle na MSSQL, co za niespodzianka.
  • Odpowiedz
@CortesHernan: Fakt. To trochę inaczej.

O ile dobrze rozumiem, to jednak dane będą musiały zostać przepchane przez sieć zanim zostaną obrobione. Chyba że procedury w bazie danych je wygenerują.

Może być źle jak ten kod z usługi się rozejdzie po aplikacjach klienckich i bazie danych.
  • Odpowiedz
Może być źle jak ten kod z usługi się rozejdzie po aplikacjach klienckich i bazie danych.


@atomowy_grzyb: Obawiam się właśnie jak przejdzie duża część do klienta. Co chyba nie jest dobrym pomysłem. Jeżeli dobrze sie wyedukowałem to klient powinien być warstwą wyświetlająca (UI) a nie wykonywać jakiekolwiek operacje na modelu?
  • Odpowiedz
@CortesHernan: Dokładnie.

Jeżeli logika biznesowa gdzieś istnieje to znaczy że jest potrzebna. Likwidując kod z kontrolerów po prostu znajdzie się w innym miejscu. Czy to problem to zależy od wielkości aplikacji.
  • Odpowiedz