Nie mogę się doszukać jakie są wytyczne, zasady, wzorce projektowe, uzasadnienia itp. jak rozdzielać logikę biznesową pomiędzy systemem bazy danych (PL/SQL), a częścią backend (JAVA). Pytam tak ogólnie, ale najbardziej zależy mi na parze PL/SQL i JAVA.
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
- Postów:4882
4
pracowalem przy projektach gdzie baza wykonywala logike a interfejs byl pisany w jakims jezyku, a takze pracowalem ze baza robila co najwyzej zapytania (no byly jakies 4-5 procedur).
Utrzymywanie i rozwijanie projektu moim zdaniem jest duzo prostsze, gdy nie ma logiki w SQL.
edytowany 1x, ostatnio: fasadin
- Rejestracja:ponad 9 lat
- Ostatnio:12 dni
- Postów:1082
3
fasadin napisał(a):
Utrzymywanie i rozwijanie projektu moim zdaniem jest duzo prostsze, gdy nie ma logiki w SQL.
Podpisuję się pod tym obiema rękami Akurat u mnie w pracy ja wyznaję zasadę, że baza tylko trzyma dane. Natomiast kolega używa dużo wyzwalaczy, do wybierania danych ma procedury, czasem nawet dość duże. Efektem tego jest to, że ja szybciej wprowadzam zmiany w systemie i całość ogólnie jest bardziej czytelna.
- Rejestracja:prawie 11 lat
- Ostatnio:24 dni
- Lokalizacja:Londyn
- Postów:873
1
To co napisali koledzy wyżej, czyli logika tylko w kodzie, poza bazą.
Uzasadnienia:
Łatwiej utrzymać taki kod i wprowadzać zmiany (później szczegóły)
Nie jest wolniej wcale, lub nie wiele wolniej (nie zauważalnie) przy większości projektów. Jak jest wolno, można pisać trochę więćej SQL w kodzie i dalej trzymać poza bazą.
Łatwiej wersjonować kod, niż procedury w bazie. Są do tego pomocne frameworki, ale koniec końców łatwiej zmienić kod niż zapisaną procedurę.
Mając więcej rzeczy w kodzie, łatwiej je wyszukać, między innymi poprzez powiązania pomiędzy obiektami.
Jest to też czytelne gdy logika siedzi w obiektach, a nie w bazie. Jedno miejsce do szukania, nie dwa. Nie zastanawiasz się czemu to tak działa jak czytasz kod.
Testowalność: Kod jest dużo łatwiej testować niż logikę w bazie. Zmieniając kod, gdy masz sporo testów, powiedzą Ci szybko że coś popsułeś. Przy testowaniu logiki w bazie nie jest już tak różowo. Łatwo zapomnieć, że dodało się nowy obiekt/tabelę i teraz trzeba zmodyfikować 3 procedury, żeby logika trzymała się kupy. W kodzie przy testach zwłaszcza, wyjdzie to szybciej, lub nawet od razu przy pisaniu kodu.
Plus:
Możesz poczytać o DDD, jeśli chodzi o architekturę skomplikowanych domen.
- Rejestracja:prawie 9 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:UK
- Postów:2235
0
Osobiście nie widzę nic złego w używaniu stored procedures pod warunkiem że oganiczają się do prostych transakcji typu Add, Update, Delete, Get etc. Choć sam w swoich projektach preferuję mieć to w kodzie to nie zgadzam się co do tego że jest to łatwiejsze do wdrożenia zmian. Szczególnie jeśli mowa o pełnoprawnym oprogramowaniu używanym przez klienta. Jeśli okazuje się że gdzieś jest błąd i na mus trzeba go naprawić to prościej zaktualizować procedurę po stronie serwera niż zrobić zmianę w kodzie, skompilować, przepuścić przez QA i wypuścić do klienta.
- Rejestracja:ponad 10 lat
- Ostatnio:7 miesięcy
- Postów:597
0
Ja pracuje z projektem gdzie cała logika jest po stronie bazy danych. Projekt ma swoje lata. Warstwa ta urosła do gigantycznych rozmiarów, przebijanie się przez rozbudowane procedury składowane jest często męczarnią. Dlatego osobiście jestem po stronie logiki biznesowej w kodzie aplikacji - łatwiej testować, łatwiej utrzymać.