[CortesHernan]

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

[Pipcieo]

Dodatkowo używamy różnych funkcji HTTP ( GET , POST itp) poprzez prefixy w nazwach funkcji ( np. funkcja dodawania danych nazywa się POSTjakiesdanecostam().

@CortesHernan: WAT?

[CortesHernan]

@Pipcieo: metod, sorki ;)

[Pipcieo]

@CortesHernan: ale, że co
robicie
GET GETcostam
GET POSTcostam
GET DELETEcostam
?

zamiast
GET costam
POST costam
DELETE costam

[d.....x]

Ja mam podobnie tj część funkcjonalności jest na bazie danych ze względu na to, że na bazie działa wiele aplikacji w różnych technologiach, a większość programistów zna plsqla.
Jest to totalnie #!$%@?-debugowanie jest trudne ze względu na rozwaloną logikę.
Ja tam jestem zdania, że baza danych powinna zawierać jak najmniej logiki. Jedyne usprawiedliwienie to przrtwarzanie jakichś mega ilości rekordów, których nie ma sensu pchać po sieci.

[CortesHernan]

@Pipcieo: troche to bardziej skomplikowane. Funckja na bazie wyglada tak:

getcostam

z JS request wyglada
GET costam

serwer rozpoznaje jaka jest metoda i sam dodaje prefix. Dzieki temu np. mamy funkcje

getuser
postuser
putuser
deleteuser

a z js wyglada tak
GET user
POST user
PUT user
DELETE user

i mozemy dokładać nowe "zasoby" bez zmian na serwerze, jedynie wrzucic nowa funkcję do bazy. Pytam o opinie o takim rozwiązaniu.

[CortesHernan]

@dixx: Przyznaję racje co do debugowania, jest #!$%@?, jeżeli pomylisz się przy pisaniu funkcji i np. nie zwraca dokładnie tego co chciałeś i potem zdziwko ze w aplikacji klienta nie ma tego czego oczekujemy.

[Pipcieo]

@CortesHernan: jezeli na poziomie http (nie ma czegoś takiego jak js w tym temacie) macie normalne get/post/put/delete (czyli nie ma dziwactw) to OK.

a co do samego pomysłu i tego co napisał @dixx

to zależy ( ͡º ͜ʖ͡º)

[CortesHernan]

@Pipcieo: Czyli pomysł nie był aż tak #!$%@? :D to git. Troche się boję co będzie dalej.

[markaron]

@dixx: @CortesHernan: Ja jestem przeciwnikiem trzymania logiki w bazie danych bo takie podejście błędnie zakłada, że to baza danych jest najważniejszą częścią aplikacji, a tak nie jest. Najważniejszą częścią aplikacji jest silnik reguł biznesowych, który powinien być niezależny od innych elementów aplikacji. Cała wartość aplikacji siedzi w regułach biznesowych, które przetwarzają, liczą i analizują. Reszta to tylko dodatki.

[Pipcieo]

@markaron: ech, młodzieży
trzymanie logiki w bazie danych nie implikuje, że bd jest najważniejszą częścią, a jedynie unifikuje / umożliwia / wymusza dostęp do danych
ideowe odrzucanie logiki w bazie danych to krótkowzroczność (a raczej brak doświadczenia) i prowadzi do duplikowania kodu w różnych aplikacjach w różnych technologiach

kolejny błąd to podejście na zasadzie, że coś jest najważniejsze i tym samym porównywanie bazy danych do aplikacji. bez zmiany tego podejścia będzie

[CortesHernan]

@Pipcieo: Dzięki za wsparcie. Na początku ten pomysł mi się podobał, ale teraz miałem małe obiekcje czy to nie przysporzy kłopotów w przyszłości. Trochę nam to przyspieszyło produkcję, bo ludzie piszący moduły aplikacji klienta nie muszą znać np. javy by dopisać nową funkcjonalność.
Też uważam, ze czasem sztywne trzymanie się niektórych zasad spowalnia pracę.

[d.....x]

@markaron: No dobra. Ale jak masz aplikację w Oracle Forms zrobioną kilkanaście lat temu, która jest dalej utrzymywana i pelni funkcję głównego systemu, na tej bazie kilka innych aplikacji w różnych technologiach typu php, jee, sterowniki do urzadzen to nie bardzo masz gdzie od tego uciec-baza będzie najważniejszą częścią infrastruktury

[markaron]

@Pipcieo: Tak się składa, że doświadczenia mam dość i moje podejście jest właśnie podyktowane doświadczeniem. Trzymanie całej logiki w bazie danych wiąże aplikację z konkretną bazą danych i jest trudne w utrzymaniu. A jest tym trudniejsze im większy system. Dobry projekt warstwy logiki biznesowej i nie będzie żadnego duplikowania kodu.

@dixx: Nie pisałem w kontekście starych systemów, tylko nowych. Trzymanie logiki w bazie danych to jest właśnie stare podejście od

[Pipcieo]

Trzymanie całej logiki w bazie danych wiąże aplikację z konkretną bazą danych i jest trudne w utrzymaniu.

@markaron: nic nie pisałem o CAŁEJ logice. Jednocześnie nie uzasadniłeś dlaczego jest trudne w utrzymaniu. W praktyce nie ma to żadnego związku.

Dziś nie masz pewności co będzie twoim źródłem danych za jakiś czas.

A masz pewność co będzie klientem do twoich danych?

Nie życzę wam sytuacji, gdy przyjdzie klient i będzie chciał żeby

[d.....x]

Nie życzę wam sytuacji, gdy przyjdzie klient i będzie chciał żeby aplikacja chodziła np na MS SQL a nie Oracle.

@markaron: nie ma obawy, aplikacja jest na własne potrzeby. To wygląda raczej tak, że podwykonawca dostaje zlecenie:
Zrobić stronę internetową do obsługi kart płatniczych.
Nas grzeje technologia w jakiej to wykona, ale wykonawca nie dostanie logiki np walidacji transakcji na karcie, czy blokowania. Dostaje nagłówki procedur składowanych i tyle.

To oczywiście

[markaron]

@Pipcieo:

nic nie pisałem o CAŁEJ logice.

Ok zagalopowałem się w takim razie.

Jednocześnie nie uzasadniłeś dlaczego jest trudne w utrzymaniu. W praktyce nie ma to żadnego związku.

Sql jest językiem deklaratywnym, dużo trudniejszym w analizie i debugowaniu. Poza tym nie oferuje możliwości jakie daje OOP, a które pozwalają wygodnie modelować złożone procesy biznesowe. Podobnie jest z brakiem podejścia funkcyjnego, które czasami pozwala rozwiązać pewne problemy dużo łatwiej i czytelniej niż

[Kaczus2B]

@dixx: Ja jestem odmiennego zdania, logika powinna być albo na bazie, albo w serwisie, inaczej jak działa ci kilka programow, i grzebie bezpośrednio po bazie, to potrafi skutecznie roz***lic dane w bazie, szczególnie jeśli to nie sa proste strony www z tekstem.
@CortesHernan: co masz do MS SQL? - no tak mogła być jeszcze baza Oracle'a, albo Pervasive'a z darmowych ewentualnie brałbym pod uwagę PostgreSQL-a.

[markaron]

@dixx: Jeżeli aplikacja jest na własne potrzeby to jeszcze da się takie podejście zrozumieć. Nasz system, jak powstawał też nie był przewidziany do pracy z innym silnikiem jak MS SQL.

Na szczęście ktoś pomyślał i zadbał o separację warstw już na samym początku (tworząc abstrakcję nad bazą danych w postaci biblioteki, która jest takim mini ORMem). Dzięki temu mogliśmy łatwo przystosować aplikację do pracy z Oraclem.

Oprócz tego dzięki dodatkowej separacji

[Pipcieo]

@markaron:

Sql jest językiem deklaratywnym, dużo trudniejszym w analizie i debugowaniu. Poza tym nie oferuje możliwości jakie daje OOP, a które pozwalają wygodnie modelować złożone procesy biznesowe. Podobnie jest z brakiem podejścia funkcyjnego, które czasami pozwala rozwiązać pewne problemy dużo łatwiej i czytelniej niż choćby OOP.

A kto powiedział, że logikę w bazie danych trzeba pisać w SQL? To byłby masochizm (⌐ ͡■ ͜ʖ ͡■)
Jest

[Kaczus2B]

@markaron: Jak będzie chciał zmienić bazę to i tak te genialne zapytania, które miałeś stworzone będą do luftu - bo na innej bazie mogą być nieoptymalne, albo wręcz nie będą działać.Właśnie podejście, że do bazy dostajesz się przez pewien interface ma tą zaletę, że jak zmienisz bazę, to właśnie zapytania w kodach się nie zmienią, co najwyzej będzie trzeba zmienić to, ze dostawać się będziemy do innej bazy. Ewentualnie jest od