Ciekawe podejście. Twierdzisz, że lepiej, żeby więcej kodu bylo w tej części systemu, do której się nie dotykasz, bo będziesz mieć mniej pracy. Ale bazodanowiec przecież powie cos dokładnie przeciwnego, będzie chciał mniej kodu w sql, wiecej w C#. Które z was będzie miało rację?
Źle mnie zrozumiałeś. Nie chodziło mi o stosowanie spychologii, tylko o to, by każdy zajmował się swoją częścią systemu. Np. css nie powinien się znajdować na backendzie, nawet jeśli akurat jakiś backendowiec sobie wymyśli, że jak do tych danych doda magicznie css to będzie łatwiej i szybciej. Widziałam backendowców, którzy wciskali w swój kod skrypty jQuery i go niemal na siłę dociskali do wyniku, obrzydliwość. Css/js to nie jest problem backendowca i nie powinien być, nie dlatego, że jest leniwy, tylko dlatego, że narobi syfu.
Tak samo nie lubię widzieć w kodzie fragmentów sql i skomplikowanych zapytań ORMowych. Nie dlatego, że jestem taka leniwa i chcę, żeby ktoś inny się tym zajął, tylko dlatego, że nie jestem specjalistą od baz danych. Założyłeś, że bazodanowiec powie coś dokładnie przeciwnego. Z mojego doświadczenia - bazodanowcy chętnie biorą kod do siebie, jeśli też uważają, że to akurat powinno być po stronie bazy. Nie wiem, jak go organizują i testują, bo ja się zajmuję czym innym. Za to bazodanowcy zajmują się właśnie tym, by dane były sensownie zorganizowane, indeksy ponakładane gdzie trzeba i żeby listowanie różnych rzeczy bazy danych nie zajeżdżało.
Zatem więcej spaghetti-kodu, bo sql ciężko dzieli się na klasy i metody. Za tem mniej testów lub ich brak, bo sql po stronie bazy danych trudniej się testuje. Sql jest jak assembler, generalnie nie nadaje się do implementacji dużej ilości logiki (z pewnymi wyjatkami).
Poproszę tu jakichś bazodanowców do dyskusji ;) Ci, których znam (też spoza WK :P), nie uważają swojego kodu za spaghetti-code. Ja natomiast, jak patrzę na te miejsca, gdzie próbowałam jakieś skomplikowany joiny w ormie zrobić, to płakać mi się chce i nie chcę tam wracać.
Jak sama napisałaś, pomiędzy klientem a bazą masz API, które w razie większych zmian w bazie zwykle zapewni wsteczną kompatybilność. Cienki klient, jakim jest przeglądarka internetowa, nie potrzebuje takiej kompatybilności w ogóle. Dodanie warstwy abstrakcji po stronie danych w postaci np. view albo sp nie zagwarantuje uniknięcia wymuszenia zmian w klientach, spowoduje za to dodanie jeszcze jednej warstwy, którą trzeba utrzymywać - dokumentować zmiany, przykrywać te zmiany testami, wdrażać nowych programistów w działanie. Po co nowa warstwa, kiedy jej zadanie może spełnić warstwa już istniejąca?
Jeśli masz API, to jasne, API może spełniać funkcję takiej warstwy. Nie zawsze masz API. Czy zawsze powinno być API?
BTW "skomplikowane joiny", co to takiego?
No daj spokój, nie chodziło mi przecież o to, że join jest skomplikowany :D Nie widziałeś takich potworków w ORMach, gdzie coś, co mogłeś napisać prościutkim sqlem z jednym joinem na maks 100 znaków, w ORMie wymaga 15 linijek dziwnych konstrukcji...? Ja widziałam... aczkolwiek akurat nie w EF, a w Doctrine.
No i na koniec może podkreślę, że ja przecież nie mówiłam o implementowaniu dużej ilości logiki. Mówiłam o pewnej warstwie logiki. Żeby rozstrzygać dogłębniej, musielibyśmy rozmawiać o konkretnych przypadkach, i zastanowić się, czy to już za dużo logiki, czy jeszcze nie za dużo...
grzesiek51114