Kompletnie zielony z Zenda - uczę się

Witam,

Zaczynam, ale w nietypowy sposób, mam własną klasę do łączenia się z Oraclem, i tam oprogramowane wiele funkcji (PHP).

Klasa nazywa się TServerOra i łaczy się z oraclem za pomocą funkcji "oci_connect" - w sumie nie ważne.

Teraz mam kilka pytań:

1. Gdzie mogę zadeklarować zmienną w której utworzę obiekt TServerOra i jak uzyskiwać dostęp z poszczególnych views/script/*.phtml
2. Gdzie utworzyć instancję tej klasy (gdzie ją zainicjować)? może - Bootstrap? jeśli tak to jak? aby się samo wykonało czy mam to gdzieś uruchomić.

Sory za głupie pytania, ale ponoć nie ma głupich pytań, po prostu nie wiem gdzie zadeklarować w Zendzie aby to było tak jak ma być.
W sumie dotyczy to dowolnych obiektów do których chcę mieć dostęp z dowolnego miejsca.

Dzięki,
Tomek

Gdzie mogę zadeklarować zmienną w której utworzę obiekt
Utworzysz zmienną w obiekcie? To zdanie nie ma sensu.
To, o czym mówisz, to instanizacja (instanization), czyli utworzenie obiektu klasy (oraz przypisanie tej nowo utworzonej referencji do zmiennej).

(...) i jak uzyskiwać dostęp z poszczególnych views/script/*.phtml
O nie, nie, nie - w widoku nie powinno być żadnego tworzenia modeli.
Jak brzmi nazwa - widok powinien służyć tylko do prezentacji danych przesyłanych mu z kontrolera.

Nie wiem, co konkretnie próbujesz zrobić, ale masz dwa wyjścia:

1. Tworzyć instancję w kontrolerze (w poszczególnych akcjach albo generalnie w metodzie init).
2. Tworzyć na początku życia aplikacji i zapisywać do Zend_Registry.

No jak już pisałem - piszę dlatego, że nie wiem jak to zrobić w zendzie, potrzebuję mieć obiekt dostępowy do bazy do którego mogę odwoływać się z każdego miejsca ... od cała filozofia, nie czepiaj się słówek, gdyż nie jestem początkującym programistą, wiem co to referencja, klasa, instancja klasy czyli obiekt... tylko jestem zielony jeśli chodzi o Zenda, czyli gdzie utworzyć instancję takiego obiektu, gdzie utworzyć zmienną przechowującą wskaźnik do tego obiektu... ? Ps. ja nie chcę tworzyć żadnych modeli, mam bazę danych i całą logikę biznesową w niej (oracle) więc chcę tylko wywoływać funkcje, procedury bazodanowe ale jak to już mówiłem to już mam. Zresztą nie widzę potrzeby tworzenia modelu bazy danych po stronie zenda bo i po co mieszać bazę danych z interfejsem użytkownika jakim jest WWW... Zresztą w sumie mi to już działa, na razie utworzyłem zmienną globalną w layouts/script/layout.phtml i odwołuję się do niej po klauzuli global, ale rozumiem, że tego się tutaj tak nie robi... Rozumiem, że jedną z opcji które chyba rozumiem, to tworzyć ten obiekt w danym kontrolerze... też dobre miejsce (ino trochę głupie, bo w każdym kontrolerze muszę powielać kod tworzenia obiektu) i tylko jak później odwoływac się do tego obiektu z view/scripts/kontroler/akcja ?

nie czepiaj się słówek, gdyż nie jestem początkującym programistą
Co to w ogóle ma do rzeczy, że nie jesteś początkującym? Piszesz bzdurę w stylu utworzę obiekt w zmiennej, która nie znaczy absolutnie nic, a ja mam to puścić płazem bo niby nie jesteś początkujący?
Pamiętaj, że znajdujesz na forum - to naturalne, że wszelkie niejasności w poście będą Ci wywłaszczone.

Zresztą nie widzę potrzeby tworzenia modelu bazy danych po stronie zenda bo i po co mieszać bazę danych z interfejsem użytkownika jakim jest WWW
Huh?
Dawno temu strony internetowe przestały być samymi interfejsami, a stały się pełnoprawnymi aplikacjami, w związku z czym pisanie ich w klarowny sposób (tj. z wykorzystaniem przykładowo wzorca MVC, którego już pierwszy człon stanowi słowo model) nie powinno nikogo dziwić.
Przerzucanie absolutnie całej logiki do bazy danych jest dla mnie dosyć dziwne i niespotykane.

ino trochę głupie, bo w każdym kontrolerze muszę powielać kod tworzenia obiektu
Wcale nie musisz - przecież możesz sobie zrobić jakiś swój abstrakcyjny kontroler, w którym będzie to łącznie się z bazą, a po którym będą dziedziczyć inne kontrolery.
Choć moim zdaniem to może być overkill - najprościej (oraz według mnie - najlepiej) będzie zrobić własny bootstrap, gdzie instancję obiektu będziesz wrzucał do rejestru (Zend_Registry).

tylko jak później odwoływac się do tego obiektu z view/scripts/kontroler/akcja ?
Technicznie nie powinieneś - cała logika związana z przetwarzaniem danych powinna być zawarta w kontrolerze, a widok powinien otrzymywać np. samą tablicę wynikową.
Pod żadnym pozorem nie przenoś logiki biznesowej do widoku.

OK co do bzdury napisałem, ale ok wiadomo o co chodzi. Co do logiki w bazie danych, no cóż - może dlatego, że nie jest to prosta strona www ... i rozumiem, że mySQL nie daje takich możliwości jak Oracle i trzeba się posiłkować przeniesieniem logiki biznesowej do strony WWW... Jednak w moim projekcie, z tej samej bazy danych jak i logiki korzysta zarówno www jak i aplikacja jak i dane te i logika jest sprzedawana na zewnątrz, więc nie za bardzo rozumiem jaki plus było by przenoszenie tej logiki na każde środowisko, kto by utrzymał 3 wersje tej samej logiki biznesowej? - totalna bzdura. Dobrze poza argumentem "że tak się nie robi" - podać jakieś argumenty.

"...najprościej (oraz według mnie - najlepiej) będzie zrobić własny bootstrap, gdzie instancję obiektu będziesz wrzucał do rejestr(Zend_Registry)." - to jest prawdopodobnie to czego bym potrzebował, żebym tylko jeszcze wiedział jak to zrobić - ale pójdę tym krokiem.

ps. a propoS przenoszenia logiki biznesowej do widoku... nigdzie nie pisałem o tym, piszę natomiast że logikę całą mam w Oracle'u.

TT

tdoberman napisał(a):

Dobrze poza argumentem "że tak się nie robi" - podać jakieś argumenty.
Chcesz to masz. Ja nigdy nie daję logiki w bazie danych ponieważ zawsze istnieje jakieś prawdopodobieństwo, że zechcemy zmienić system bazodanowy. Co wtedy? Nie w każdym systemie baz danych można zrobić takie same rzeczy. I wtedy masz problem. Znam aplikacje które mogą używać różnych systemów. Klient podczas instalacji wybiera czy chce Oracla, czy MySQL, czy MSSSQL. Co wtedy? Zaszyta logika w bazie danych uniemożliwia coś takiego. Poza tym baza danych niech robi to do czego została stworzona, czyli gromadzenie danych oraz ewentualne sprawdzanie integralności danych za pomocą no. kluczy zewnętrznych czy indeksów unikalnych.

w moim projekcie, z tej samej bazy danych jak i logiki korzysta zarówno www jak i aplikacja jak i dane te i logika jest sprzedawana na zewnątrz, więc nie za bardzo rozumiem jaki plus było by przenoszenie tej logiki na każde środowisko, kto by utrzymał 3 wersje tej samej logiki biznesowej?
Co, co, co?
Dostęp do bazy danych powinien być ograniczony do jednego serwera, który udostępnia na zewnątrz zunifikowane API - trzy różne środowiska mające dostęp do tej bazy danych to ogromny błąd projektowy.

o jest prawdopodobnie to czego bym potrzebował, żebym tylko jeszcze wiedział jak to zrobić - ale pójdę tym krokiem.
W dokumentacji Zenda piszą o tworzeniu własnego Bootstrapa, a Zend_Registry jest stosunkowo proste do obsługi.

przenoszenia logiki biznesowej do widoku... nigdzie nie pisałem o tym, piszę natomiast że logikę całą mam w Oracle'u.
Tak, ale z tego co zrozumiałem, próbujesz przenieść odpowiedzialność za pobranie danych do widoku... do samego widoku. A to jest złe.
Dane powinny być pobierane w kontrolerze, a widok powinien tylko i aż je wyświetlać.

Co, co, co?
Dostęp do bazy danych powinien być ograniczony do jednego serwera, który udostępnia na zewnątrz zunifikowane API - trzy różne środowiska mające dostęp do tej bazy danych to ogromny błąd projektowy.

Dlaczego ogromy bład projektowy? - tak się to robi - może nie do końca rozumiemy o co mi chodzi... a tak ogólnie, co złego w tym, że logika biznesowa leży w jednym miejscu?

• Chyba, że inaczej rozumiemy znaczenie określenia "logika biznesowa" - w moim rozumieniu np. obliczanie ceny artykułu, np. na podstawie wielu tabel, rabatów i innych paramtrów? - ty naprawdę uważasz, że dobrze takie coś liczyć po stronie www? o wiele lepiej raz a dobrze to policzyć (funkcją, procedurą, widokiem, etc) po stronie bazy danych i wystawiać już gotowe przeliczone dane.

Tak, ale z tego co zrozumiałem, próbujesz przenieść odpowiedzialność za pobranie danych do widoku... do samego widoku. A to jest złe.
Dane powinny być pobierane w kontrolerze, a widok powinien tylko i aż je wyświetlać.

• nie, pobieram dale w formatce przez obiekt DB który pobieram tak: $db = Zend_Registry::get("db"); - dobrze tak?

Dlaczego ogromy bład projektowy? - tak się to robi
Udostępnianie dostępu do bazy danych osobom trzecim, nawet jeśli mocno ograniczone, wydaje mi się archaiczne i niezgodne z wszelkim pojęciem.
Jedną z najważniejszych zasad w programowaniu jest separation of concerns, w myśl której nie powinno się mieszać ze sobą kilku różnych warstw aplikacji (w tym wypadku złączona została warstwa biznesowa z warstwą danych) - tworzy się w ten sposób negatywny high coupling. Dodatkowo uzależnia się od specyficznego rodzaju programistów - ciężej znaleźć porządnego programistę do baz danych, który będzie to ogarniał, w porównaniu do np. rynku Javy. Oraz uzależnia się od jednego silnika bazy danych - także potrafi się negatywnie odbić.

Nie mówiąc o przypadku, gdy np. do policzenia czegoś potrzebne są dane z zewnętrznego serwera pobierane przykładowo SOAPem - wtedy tę część trzeba uwzględnić w każdej aplikacji osobno (ponieważ baza danych tego nie wykona) i zaczyna się duplikować kod. A wystarczyłoby udostępnić normalne API, które samo zajmowałoby się wszystkimi niedogodnościami.

Ponawiam: bazy danych zostały stworzone do szybkiego dostępu, przechowywania danych, a nie tworzenia w nich aplikacji.

w moim rozumieniu np. obliczanie ceny artykułu, np. na podstawie wielu tabel, rabatów i innych paramtrów
Dokładnie to należy do logiki biznesowej.

o wiele lepiej raz a dobrze to policzyć (funkcją, procedurą, widokiem, etc) po stronie bazy danych i wystawiać już gotowe przeliczone dane.
Równie dobrze można powiedzieć: o wiele lepiej raz to policzyć po stronie aplikacji, zapisać w pamięci podręcznej i mieć już gotowe dane :P

pobieram dale w formatce przez obiekt DB który pobieram tak: $db = Zend_Registry::get("db"); - dobrze tak?
"W formatce", czyli w widoku, tak?
Nie - nie dobrze. Za pobieranie danych odpowiada kontroler - widok powinien otrzymać już gotowe dane.

Udostępnianie dostępu do bazy danych osobom trzecim, nawet jeśli mocno ograniczone, wydaje mi się archaiczne i niezgodne z wszelkim pojęciem.

• bzdura totalna, zobacz jak działa np. firma BMF która posiada całą bazę danych samochodów, aplikacji, osprzętu felg, i sprzedaje tą bazę danych oraz logikę biznesową np. za pomocą webserwice, itp....

także potrafi się negatywnie odbić.

• np. jak?

Nie mówiąc o przypadku, gdy np. do policzenia czegoś potrzebne są dane z zewnętrznego serwera pobierane przykładowo SOAPem - wtedy tę część trzeba uwzględnić w każdej aplikacji osobno (ponieważ baza danych tego nie wykona) i zaczyna się duplikować kod

• a to juz po prostu brak wiedzy na temat bazy danych Oracle, który potrafi pobrać dane z FTP, www, z dowolnego portu TCP, czy SOAP... i tak się dzieje... 2-3 linie kodu i masz wszystko w jednym miejscu, dodatkowo za pomocą HS oracle łączyć się może z dowolną bazą danych i widzi jej dane jak swoje...

Ponawiam: bazy danych zostały stworzone do szybkiego dostępu, przechowywania danych, a nie tworzenia w nich aplikacji.

• nie Oracle!

Równie dobrze można powiedzieć: o wiele lepiej raz to policzyć po stronie aplikacji, zapisać w pamięci podręcznej i mieć już gotowe dane :P

• i każdy rodzaj aplikacji ma liczyć to osobno? - jak zmieniasz logikę to w kilku miejscach? jaki jest tego sens, co przemawia aby nie liczyć tego w systemie zarządzania bazą danych?

pobieram dale w formatce przez obiekt DB który pobieram tak: $db = Zend_Registry::get("db"); - dobrze tak?
"W formatce", czyli w widoku, tak?
Nie - nie dobrze. Za pobieranie danych odpowiada kontroler - widok powinien otrzymać już gotowe dane. - OK. Tak też będę próbował, wiesz... ja od 2 dni używam jakiegokolwiek frameworka, więc jak w temacie...

Widzę, że nie przemawiają do Ciebie sensowne argumenty. Napisałem posta, a Ty go w ogóle zignorowałeś, dlaczego? Uparcie bronisz swojego stanowiska. Widzę tu podejście, ze Oracle to jakaś cudowna-hiper-super-duper-wypasiona-w-kosmos baza danych której ficzery powodują, że należy łamać dobre zasady projektowania aplikacji.

Dostałem jakiś czas temu w spadku po współpracowniku taką bazę gdzie logika biznesowa została zawarta w bazie za pomocą triggerów i masy procedur. Uwierz mi, że takiego gówna mało kiedy widziałem na swoje oczy. Ani tego się nie dało porządnie debugować, ani przetestować. Ogólnie dodanie nowej funkcjonalności trwało o wiele dłużej niż w klasycznym podejściu. Po zmianie podejścia szybko dało się dodawać nowe funkcjonalności.

A co powiesz na temat testów? Jak masz chcesz testować takie moduły gdzie logika siedzi w bazie? Realnie to pisze się testy jednostkowe i już. A tu co? Musisz mieć realną bazę aby coś przetestować. Nie tędy droga. Testy nie potrzebują połączenia do bazy, a tu aby coś przetestować musisz mieć realną bazę i to jeszcze z jakimiś danymi...

bzdura totalna, zobacz jak działa np. firma BMF która posiada całą bazę danych samochodów, aplikacji, osprzętu felg, i sprzedaje tą bazę danych oraz logikę biznesową np. za pomocą webserwice, itp....
Nie wiem, nie korzystałem, nigdy nawet nie słyszałem o tej firmie - ale jeśli wystawia bazę poprzez API (czyli pomiędzy dochodzi jakiś język server-side), to jest to inny przypadek, niż mówiłem.
Poza tym taki przykład jest dosyć z czapy. Równie dobrze ja mogę powiedzieć, że nazewnictwo getUrzedyWydajaceEPrzesylki to dobra nazwa metody, bo Poczta Polska tak ma :)

a to juz po prostu brak wiedzy na temat bazy danych Oracle, który potrafi (...)
Okej, zwracam honor, nie miałem pojęcia, że baza danych ma obsługę FTP i całej innej rzeszy tych rzeczy. Prawdę mówiąc nigdy nawet bym nie wpadł na pobieranie czegoś za pomocą bazy danych :|
Tym nie mniej: tylko dlatego, że można, nie znaczy, że jest to prawidłowe. Albo przydatne. Albo cokolwiek innego. PHP możesz kompilować do exe... tylko po co?
Utrzymuję, że więcej ficzerów = więcej kodu aplikacji. Więcej kodu aplikacji = więcej bugów (ot - średniowieczne motto). A bugi w bazie danych to coś cholernie niepożądanego.

i każdy rodzaj aplikacji ma liczyć to osobno? jak zmieniasz logikę to w kilku miejscach?
Tłumaczyłem Ci przecież - wystawiam na zewnątrz świata API i wszelkie zmiany wykonuję w jednym miejscu: u siebie, w tym swoim API. Optymalnie moje aplikacje też korzystają z tego samego API, i wszystko działa jak w zegarku.
A gdy chcę dokonać ważnej aktualizacji w API łamiącej kompatybilność, mogę sobie zrobić osobny serwis pod adresem http://api.mojastrona.pl/v1/ i http://api.mojastrona.pl/v2/. I wszyscy szczęśliwi.

jaki jest tego sens, co przemawia aby nie liczyć tego w systemie zarządzania bazą danych?
Technicznie mógłbyś wykorzystać osobówkę jak autobus... tylko po co, skoro istnieją autobusy?
System zarządzania bazą danych służy właśnie temu, czemu brzmi jego nazwa - zarządzaniu bazą danych. Wykonywanie operacji w stylu pobierz mi 10 ostatnio dodanych produktów, do każdego dociągnij z osobnego serwera zdjęcia i skompresuj mi to jako pole w rezultacie zapytania nie ma nic z tym wspólnego i, co najważniejsze, bazy danych nie są tworzone z nastawieniem na te ficzery.
Baza danych ma być wydajna oraz konfigurowalna - a to, że ma sobie obsługę TCP, FTP, produkcji amfetaminy czy parzenia kawy... no ok, niech ma, ale i tak lepsze rezultaty osiągnie się w języku, który jest dedykowany do takich szerokich zastosowań.

wiesz... ja od 2 dni używam jakiegokolwiek frameworka, więc jak w temacie...
I nigdy przedtem nie słyszałeś o MVC ani MVVP? Zend nie ma nic do tego, on tylko realizuje założenia tych wzorców architektonicznych.

Widzę, że nie przemawiają do Ciebie sensowne argumenty
.

• no właśnie, żaden nie padł - a nie znam technologi pisania stron www - bo nie jestem programistą www, tylko programistą i administratorem baz danych oraz programistą C#, C++, Delphi.

Widzę tu podejście, ze Oracle to jakaś cudowna-hiper-super-duper-wypasiona-w-kosmos baza danych której ficzery powodują, że należy łamać dobre zasady projektowania aplikacji

• nie znam się na tych technikach, ja jestem programistą aplikacji typli klient serwer i trójwarstwowych - wtedy warstwa biznesowa jest po środku. Jakbym usłyszał jakieś fajne argumenty za i przeciw to OK, a na razie usłyszałem, że nie da się łączyć z SOAP - to napisałem, że się da i tyle... prowadzę wielki projekt w kilku fabrykach od ponad 15 lat, i nie mam czasu na nowe technologie, ktore jakoś mnie nie przekonują jak widzę przykładowy kod.

Dostałem jakiś czas temu w spadku po współpracowniku taką bazę gdzie logika biznesowa została zawarta w bazie za pomocą triggerów i masy procedur. Uwierz mi, że takiego gówna mało kiedy widziałem na swoje oczy. Ani tego się nie dało porządnie debugować, ani przetestować. Ogólnie dodanie nowej funkcjonalności trwało o wiele dłużej niż w klasycznym podejściu. Po zmianie podejścia szybko dało się dodawać nowe funkcjonalności.

• tak samo jak ja nie umiem testować podejścia o którym ty piszesz, tak samo ty nie umiesz testować podejścia o którym ja mówię.

A co powiesz na temat testów? Jak masz chcesz testować takie moduły gdzie logika siedzi w bazie? Realnie to pisze się testy jednostkowe i już. A tu co? Musisz mieć realną bazę aby coś przetestować. Nie tędy droga. Testy nie potrzebują połączenia do bazy, a tu aby coś przetestować musisz mieć realną bazę i to jeszcze z jakimiś danymi...

• na temat testów jednostkowych (w tym przykładzie) się nie wypowiem i przyjmę za dobrą monetę, że tak jest, jednak odpowiednie podejście i wygenerowanie baz danych na 10 lat do przodu, powoduje, że ja ze swoimi aplikacjami nie mam problemów, szczególnie jak się je postawi przy podobnych aplikacjach pisanych w sposób jak mówisz - a kosztujących miliony... Być może to jest kwestia specyfiki czym się aplikacja zajmuje, moje aplikacje są klasy MESS a tam są pisane aplikacje w ten sam sposób co moje, wiem bo z kilkoma walczymy w firmie... tam co chwilę są problemy w mojej mogę iść na urlop spokojnie nie musi czuwać sztab informatyków - więc sama technologia fajna, być może - podkreślam jej nie znam - ale to nie wszystko.

Ale skoro moje produkty są używane w kilku fabrykach, również poza granicami i są najlepiej oceniane z systemów które tam działają, to coś w tym musi być, i być może specyfika na to pozwala - żeby tak było.

I sory, ale jak widzę te rozwiązania mega technologie o których mówisz, i całą stronę kodu która zastępują jedna lub dwie w oraclu... to ręce opadają...

tdoberman napisał(a):

• no właśnie, żaden nie padł - a nie znam technologi pisania stron www - bo nie jestem programistą www, tylko programistą i administratorem baz danych oraz programistą C#, C++, Delphi.
  Ja też jestem programistą C++ Buildera. Ale technologie pisania raczej nie będą aż tak różne w przypadku www czy aplikacji desktopowej. Jak dla mnie minusem trzymania logiki w bazie jest:

• silne uzależnienie się od danego systemu bazodanowego. Osobiście wolę w każdej chwili mieć możliwość przejścia na inny serwer bez dużych zmian. Tutaj nie masz takiej możliwości, bo nie każdy system bazodanowy musi umożliwiać wszystko czego Ci trzeba do zaszycia logiki w bazie.
• brak możliwości sensownego przetestowania takiego rozwiązania. Przecież nie napiszesz testów jednostkowych dla triggerów na bazie.

nie znam się na tych technikach, ja jestem programistą aplikacji typli klient serwer i trójwarstwowych - wtedy warstwa biznesowa jest po środku. Jakbym usłyszał jakieś fajne argumenty za i przeciw to OK, a na razie usłyszałem, że nie da się łączyć z SOAP - to napisałem, że się da i tyle... prowadzę wielki projekt w kilku fabrykach od ponad 15 lat, i nie mam czasu na nowe technologie, ktore jakoś mnie nie przekonują jak widzę przykładowy kod.
I nie widzisz z własnego doświadczenia, że taka architektura jest lepsza niż mieszanie logiki z bazą? Tak samo jak nie mieszamy logiki biznesowej z kodem GUI. To są zupełnie inne rzeczy i należy to rozdzielić.

• tak samo jak ja nie umiem testować podejścia o którym ty piszesz, tak samo ty nie umiesz testować podejścia o którym ja mówię.
  Więc jak chcesz przetestować sensownie logikę zawartą w bazie?

• na temat testów jednostkowych (w tym przykładzie) się nie wypowiem i przyjmę za dobrą monetę, że tak jest, jednak odpowiednie podejście i wygenerowanie baz danych na 10 lat do przodu, powoduje, że ja ze swoimi aplikacjami nie mam problemów, szczególnie jak się je postawi przy podobnych aplikacjach pisanych w sposób jak mówisz - a kosztujących miliony... Być może to jest kwestia specyfiki czym się aplikacja zajmuje, moje aplikacje są klasy MESS a tam są pisane aplikacje w ten sam sposób co moje, wiem bo z kilkoma walczymy w firmie... tam co chwilę są problemy w mojej mogę iść na urlop spokojnie nie musi czuwać sztab informatyków - więc sama technologia fajna, być może - podkreślam jej nie znam - ale to nie wszystko.
  Oczywiście, że można podać przykład że można napisać aplikację dobrze. Można też mieć idealną architekturę, ale tez masę błędów. Kwestia organizacji oraz testowania. Moim zdaniem to, że aplikacja ma błędy to wina testów czy polityki firmy, a nie architektury czy technologii.

Ale skoro moje produkty są używane w kilku fabrykach, również poza granicami i są najlepiej oceniane z systemów które tam działają, to coś w tym musi być, i być może specyfika na to pozwala - żeby tak było.
Nie mam pojęcia. Ciężko to po prostu ocenić. Jednak jeśli aplikacja jest dobrze oceniana to tak jest.

I sory, ale jak widzę te rozwiązania mega technologie o których mówisz, i całą stronę kodu która zastępują jedna lub dwie w oraclu... to ręce opadają...
Być może używasz nieodpowiedniego narzędzia? Nie oszukujmy się, ale pisząc w C++/Delphi tworzy się więcej kodu niż pisząc w takiej Javie czy C#. Widzę to chociażby po np. obsłudze podpisu elektronicznego. Więc pytanie czy nie warto zmienić narzędzia w którym się pisze?

Osobiście wolę w każdej chwili mieć możliwość przejścia na inny serwer bez dużych zmian

• tylko po co zmieniać bazę danych na gorszą?. z testami się mogę zgodzić.

I nie widzisz z własnego doświadczenia, że taka architektura jest lepsza niż mieszanie logiki z bazą? Tak samo jak nie mieszamy logiki biznesowej z kodem GUI. To są zupełnie inne rzeczy i należy to rozdzielić.
no tak czy się mylę, że w takiej architekturze, programista java/php musi odpowiadać za zapytania do bazy danych? czy to nie jest mieszanie? Przy bazach mających wiele milionów rekordów - staje się to uciążliwe, bo nie jest to wydajniejsze od samej bazy danych a i wiedza bazodanowa jest wymagana przez takiego programistę - jest to też minus.

I sory, ale jak widzę te rozwiązania mega technologie o których mówisz, i całą stronę kodu która zastępują jedna lub dwie w oraclu... to ręce opadają...
Być może używasz nieodpowiedniego narzędzia? Nie oszukujmy się, ale pisząc w C++/Delphi tworzy się więcej kodu niż pisząc w takiej Javie czy C#. Widzę to chociażby po np. obsłudze podpisu elektronicznego. Więc pytanie czy nie warto zmienić narzędzia w którym się pisze?
no właśnie pisząc to samo w javie/phpie/zendzie widzę jak tego kodu jest znaczeni więcej, co do futerów lub gotowych rozwiązań wiadomo, że więcej tego jest do bardziej popularnego rozwiązania jakim jest Java...

Kończąc temat, być może jakbym usiadł i aplikację od podstaw napisał pod okiem doświadczonego osobnika w javie, to bym wtedy zmienił zdanie. Czyli ile za godzinę? i zaczynamy...;)

tdoberman napisał(a):

• nie znam się na tych technikach, ja jestem programistą aplikacji typli klient serwer i trójwarstwowych

Doprawdy? Bo koledzy tutaj piszą o trójwarstwowych aplikacjach od początku, a Ty kompletnie negujesz sens ich istnienia.

prowadzę wielki projekt w kilku fabrykach od ponad 15 lat, i nie mam czasu na nowe technologie, ktore jakoś mnie nie przekonują jak widzę przykładowy kod.

No tak, jasne, rozwój nie jest obowiązkowy.

• tak samo jak ja nie umiem testować podejścia o którym ty piszesz, tak samo ty nie umiesz testować podejścia o którym ja mówię.

Brak chęci do testowania manualnego to nie kwestia umiejętności lecz braku czasy na głupoty.

ja ze swoimi aplikacjami nie mam problemów, szczególnie jak się je postawi przy podobnych aplikacjach pisanych w sposób jak mówisz - a kosztujących miliony...

Skoro trzeba pisać 10 razy więcej kodu, którego nie ma jak przetestować automatycznie, to muszą kosztować miliony. Szczęśliwi ci, którzy mają bogatych i głupich klientów.

mogę iść na urlop spokojnie nie musi czuwać sztab informatyków - więc sama technologia fajna, być może - podkreślam jej nie znam - ale to nie wszystko.

I powodem tego jest wepchnięcie logiki do bazy? No bez żartów.

tdoberman napisał(a):

no tak czy się mylę, że w takiej architekturze, programista java/php musi odpowiadać za zapytania do bazy danych? czy to nie jest mieszanie? Przy bazach mających wiele milionów rekordów - staje się to uciążliwe, bo nie jest to wydajniejsze od samej bazy danych a i wiedza bazodanowa jest wymagana przez takiego programistę - jest to też minus.

I remedium na to, żeby programista znał się trochę na bazach, jest wymóg, aby wszyscy ludzie w projekcie byli bazodanowcami, którzy potrafią w bazie upchnąć całą logikę?

no właśnie pisząc to samo w javie/phpie/zendzie widzę jak tego kodu jest znaczeni więcej, co do futerów lub gotowych rozwiązań wiadomo, że więcej tego jest do bardziej popularnego rozwiązania jakim jest Java...

Masz w swojej bazie klasy, dziedziczenie i generyki? Bo jeśli nie, tzn. że nie jesteś w stanie sprawnie wydzielać abstrakcji i współdzielić kodu, ani generować go dynamicznie w sposób gwarantujący poprawność wykonania.

Oczywiście, zapewne znajdziesz jakieś przypadki, w których jedna funkcja Oracle robi tyle, co kilka funkcji w normalnym języku, znajdziesz też słabo napisane aplikacje, w których kod będzie dłuższy niż równoważny kod w Oracle, tylko to nie są argumenty. Prosty przykład - w normalnej aplikacji jedną linijką kodu w rodzaju session.Save(obiekt) możesz wygenerować setki insertów do bazy, które dłubiąc w SQL musiałbyś zapisać ręcznie i nie pomylić się w nazewnictwie kolumn, parametrów, itd.

"Osobiście wolę w każdej chwili mieć możliwość przejścia na inny serwer bez dużych zmian" to przegięcie w druga stronę. Jeżeli buduje się duży system to na pewno nie zmienia się silnika baz tak z dnia na dzień bo jest to duże organizacyjne i technicznie wyzwanie. Poza tym stosowanie procedur przechowywanych czy widoków bardzo poprawia wydajność

cw napisał(a):

"Osobiście wolę w każdej chwili mieć możliwość przejścia na inny serwer bez dużych zmian" to przegięcie w druga stronę. Jeżeli buduje się duży system to na pewno nie zmienia się silnika baz tak z dnia na dzień bo jest to duże organizacyjne i technicznie wyzwanie. Poza tym stosowanie procedur przechowywanych czy widoków bardzo poprawia wydajność

O dokładnie, myślałem, że zwariowałem;) Wszędzie tam gdzie są problemy wydajnościowe, tylko baza danych sobie może z tym poradzić i jej mechanizmy czyli Oracle;)

Doprawdy? Bo koledzy tutaj piszą o trójwarstwowych aplikacjach od początku, a Ty kompletnie negujesz sens ich istnienia.

• nie neguję, w końcu procedury składowane też można uznać za 3 warstwę.

No tak, jasne, rozwój nie jest obowiązkowy.

• przy dużych projektach nie robi się takich zmian, to ma działać latami - to są fabryki, a nie blogi;)

Brak chęci do testowania manualnego to nie kwestia umiejętności lecz braku czasy na głupoty.

• bardziej brak czasu, masz rację.

Skoro trzeba pisać 10 razy więcej kodu, którego nie ma jak przetestować automatycznie, to muszą kosztować miliony. Szczęśliwi ci, którzy mają bogatych i głupich klientów.
Tak by było najlepiej, ale oni sami tak robią;)

mogę iść na urlop spokojnie nie musi czuwać sztab informatyków - więc sama technologia fajna, być może - podkreślam jej nie znam - ale to nie wszystko.

• nie chodziło mi o technologię, ze to jej zasługa, tylko bardziej o to, że nie jest taka zła.

I remedium na to, żeby programista znał się trochę na bazach, jest wymóg, aby wszyscy ludzie w projekcie byli bazodanowcami, którzy potrafią w bazie upchnąć całą logikę?
a dlaczego wszyscy mają się zajmować wszystkim? wystarczy że są ludzie od logiki biznesowej, ludzie od bazy danych i ludzie od interfesu użytkownika? czy się mylę?;)

Masz w swojej bazie klasy, dziedziczenie i generyki? Bo jeśli nie, tzn. że nie jesteś w stanie sprawnie wydzielać abstrakcji i współdzielić kodu, ani generować go dynamicznie w sposób gwarantujący poprawność wykonania.

• tak nie stosuje tych mechanizmów, ale pytanie czy bez tego da się nie żyć? i czy przy wszytkich rodzajach projektów jest to niezbędne? - raczej nie...

Oczywiście, zapewne znajdziesz jakieś przypadki, w których jedna funkcja Oracle robi tyle, co kilka funkcji w normalnym języku, znajdziesz też słabo napisane aplikacje, w których kod będzie dłuższy niż równoważny kod w Oracle, tylko to nie są argumenty. Prosty przykład - w normalnej aplikacji jedną linijką kodu w rodzaju session.Save(obiekt) możesz wygenerować setki insertów do bazy, które dłubiąc w SQL musiałbyś zapisać ręcznie i nie pomylić się w nazewnictwie kolumn, parametrów, itd.

• nie chodzi mi o to, że jakaś funkcja robi wszystko, chodzi mi ogólnie o to, że w tym modelu (MVC) piszesz masę kodu, który normalnie jest nie potrzebny ( w bazie )

tdoberman napisał(a):

• tylko po co zmieniać bazę danych na gorszą?. z testami się mogę zgodzić.
  Ale czemu na gorszą? Żeby to było takie proste jak piszesz, to by istniała tylko 1 baza danych na rynku i koniec. A tak nawet taki MySQL ma swoje zastosowania i tyle.

no tak czy się mylę, że w takiej architekturze, programista java/php musi odpowiadać za zapytania do bazy danych? czy to nie jest mieszanie? Przy bazach mających wiele milionów rekordów - staje się to uciążliwe, bo nie jest to wydajniejsze od samej bazy danych a i wiedza bazodanowa jest wymagana przez takiego programistę - jest to też minus.
Generalnie byłoby fajnie jakby programista nie musiał w ogóle klepać zapytań. Zwykle do tego można zaprząc np. ORM. Który jednak nie wszystko jest w stanie sam ogarnąć. Wtedy naturalnie będzie trzeba coś zaklepać z palca. Ale to nie jest takie częste. Jednak wiadomo, że programista powinien mieć jako takie obycie z bazami danych. No chyba, że mamy do czynienia z full stack developerem, wtedy sytuacja jest inna.

no właśnie pisząc to samo w javie/phpie/zendzie widzę jak tego kodu jest znaczeni więcej, co do futerów lub gotowych rozwiązań wiadomo, że więcej tego jest do bardziej popularnego rozwiązania jakim jest Java...
Właśnie. Więc może pora na zmianę technologii? Poza tym jakąś część można wydzielić do oddzielnych klas/bibliotek i struktura kodu będzie lepsza. Wtedy dużo rzeczy będziesz też mógł robić za pomocą paru linijek kodu.

Kończąc temat, być może jakbym usiadł i aplikację od podstaw napisał pod okiem doświadczonego osobnika w javie, to bym wtedy zmienił zdanie. Czyli ile za godzinę? i zaczynamy...;)
Raczej nie znajdziesz nikogo chętnego na takie zabawy na forum ;)

cw napisał(a):

"Osobiście wolę w każdej chwili mieć możliwość przejścia na inny serwer bez dużych zmian" to przegięcie w druga stronę. Jeżeli buduje się duży system to na pewno nie zmienia się silnika baz tak z dnia na dzień bo jest to duże organizacyjne i technicznie wyzwanie. Poza tym stosowanie procedur przechowywanych czy widoków bardzo poprawia wydajność
Tak, jednak z drugiej strony jak mocno korzystasz z procedur do zwracania wyników, to też nie jest dobrze. Spotkałem się z podejściem gdzie każde zestawienie było robione w ten sposób, że jego wyniki były brane z procedury. I jak ktoś chciał poprawić/zmienić zestawienie to potrzebna była aktualizacja bazy danych. Tak więc wszystko ma plusy i minusy.

• tak nie stosuje tych mechanizmów, ale pytanie czy bez tego da się nie żyć? i czy przy wszytkich rodzajach projektów jest to niezbędne? - raczej nie...
  W takim razie po co stosować wzorce projektowe, czy w ogóle języki wysokiego poziomu? Bez tego da się żyć i można tworzyć nawet zaawansowane projekty. Prawda jest taka, że użycie tego przyspiesza rozwój aplikacji za jakiś czas. Pisanie programu bez takich rzeczy powoduje zaciąganie coraz to nowego kredytu aby dokończyć nową funkcjonalność. Jednak po pewnym czasie wpadamy w pułapkę kredytową i nie możemy spłacić kredytu. Dokładnie chodzi o to, że nie jesteśmy w stanie realizować planowo nowych funkcjonalności. A to prosta droga do upadku systemu i dojścia do punktu w którym nie można nic dołożyć.

nie chodzi mi o to, że jakaś funkcja robi wszystko, chodzi mi ogólnie o to, że w tym modelu (MVC) piszesz masę kodu, który normalnie jest nie potrzebny ( w bazie )
Dla mnie takie podejście jest bardziej przejrzyste. Wiadomo co za co odpowiada. Programiści podczas pisania długiego projektu się zmieniają, wiadomo. Potem przychodzi nowy programista do zespołu i jego wdrożenie trwa długo. Więc to są stracone pieniądze. Jak piszesz stosując ogólnoznane metodyki czy wzorce (nawet kosztem ilości kodu) to nowy człowiek w zespole będzie miał prościej się wdrożyć i mniej czasu mu zajmie zrozumienie logiki działania całości. Nie będzie miał problemów typu, czy jak zmienię tu to gdzieś indziej mi się nie walnie. Zupełnie tak samo jak z pisaniem czytelnego kodu stosując reguły KISS/DRY i inne.

Ale czemu na gorszą? Żeby to było takie proste jak piszesz, to by istniała tylko 1 baza danych na rynku i koniec. A tak nawet taki MySQL ma swoje zastosowania i tyle.

• no tak ale jeśli klient ma potrzeby takie a nie inne i jest świadomy wyboru bazy danych a jest nim Oracle - to za inne się nie biorę, a klient nie będzie za jakiś czas chciał korzystać z gorszej, bo i po co skoro się zdecydował to znaczy, że była taka potrzeba.

no tak czy się mylę, że w takiej architekturze, programista java/php musi odpowiadać za zapytania do bazy danych? czy to nie jest mieszanie? Przy bazach mających wiele milionów rekordów - staje się to uciążliwe, bo nie jest to wydajniejsze od samej bazy danych a i wiedza bazodanowa jest wymagana przez takiego programistę - jest to też minus.
Generalnie byłoby fajnie jakby programista nie musiał w ogóle klepać zapytań. Zwykle do tego można zaprząc np. ORM. Który jednak nie wszystko jest w stanie sam ogarnąć. Wtedy naturalnie będzie trzeba coś zaklepać z palca. Ale to nie jest takie częste. Jednak wiadomo, że programista powinien mieć jako takie obycie z bazami danych. No chyba, że mamy do czynienia z full stack developerem, wtedy sytuacja jest inna.

• wiadomo przecież, że przy bardziej wymagających zapytaniach, niestety bez full stackowego developera nie da rady;) - i takie coś realizuję, mam około 10 mln transakcji na godzinę, gdzie na podobnym sofcie za kilka milionów jest około miliona transakcji i nie nadążają z dodawaniem wirtualnych corów...;)

no właśnie pisząc to samo w javie/phpie/zendzie widzę jak tego kodu jest znaczeni więcej, co do futerów lub gotowych rozwiązań wiadomo, że więcej tego jest do bardziej popularnego rozwiązania jakim jest Java...
Właśnie. Więc może pora na zmianę technologii? Poza tym jakąś część można wydzielić do oddzielnych klas/bibliotek i struktura kodu będzie lepsza. Wtedy dużo rzeczy będziesz też mógł robić za pomocą paru linijek kodu.

• tematyka którą się zajmuję nie wymaga takowych futerow;) - po prostu narzedzie jest dobrane do specyfikacji projektu.

Kończąc temat, być może jakbym usiadł i aplikację od podstaw napisał pod okiem doświadczonego osobnika w javie, to bym wtedy zmienił zdanie. Czyli ile za godzinę? i zaczynamy...;)
Raczej nie znajdziesz nikogo chętnego na takie zabawy na forum ;)

• jasne;)

cw napisał(a) dzisiaj, 07

"Osobiście wolę w każdej chwili mieć możliwość przejścia na inny serwer bez dużych zmian" to przegięcie w druga stronę. Jeżeli buduje się duży system to na pewno nie zmienia się silnika baz tak z dnia na dzień bo jest to duże organizacyjne i technicznie wyzwanie. Poza tym stosowanie procedur przechowywanych czy widoków bardzo poprawia wydajność
Tak, jednak z drugiej strony jak mocno korzystasz z procedur do zwracania wyników, to też nie jest dobrze. Spotkałem się z podejściem gdzie każde zestawienie było robione w ten sposób, że jego wyniki były brane z procedury. I jak ktoś chciał poprawić/zmienić zestawienie to potrzebna była aktualizacja bazy danych. Tak więc wszystko ma plusy i minusy.

• ale to raczej nie stanowi problemu... oczywiście jest to znane podejście, w oraclu nazywa się to Buisness inteligence ... ale przy wymagających zapytaniach, nawet takie narzędzie nie przewyższają programisty SQL... i niestety trzeba się do niego zwrócić, bo często nie dają rady...

• tak nie stosuje tych mechanizmów, ale pytanie czy bez tego da się nie żyć? i czy przy wszytkich rodzajach projektów jest to niezbędne? - raczej nie...
  W takim razie po co stosować wzorce projektowe, czy w ogóle języki wysokiego poziomu? Bez tego da się żyć i można tworzyć nawet zaawansowane projekty. Prawda jest taka, że użycie tego przyspiesza rozwój aplikacji za jakiś czas. Pisanie programu bez takich rzeczy powoduje zaciąganie coraz to nowego kredytu aby dokończyć nową funkcjonalność. Jednak po pewnym czasie wpadamy w pułapkę kredytową i nie możemy spłacić kredytu. Dokładnie chodzi o to, że nie jesteśmy w stanie realizować planowo nowych funkcjonalności. A to prosta droga do upadku systemu i dojścia do punktu w którym nie można nic dołożyć.

• wszystko zależy od projektanta...

nie chodzi mi o to, że jakaś funkcja robi wszystko, chodzi mi ogólnie o to, że w tym modelu (MVC) piszesz masę kodu, który normalnie jest nie potrzebny ( w bazie )
Dla mnie takie podejście jest bardziej przejrzyste. Wiadomo co za co odpowiada. Programiści podczas pisania długiego projektu się zmieniają, wiadomo. Potem przychodzi nowy programista do zespołu i jego wdrożenie trwa długo. Więc to są stracone pieniądze. Jak piszesz stosując ogólnoznane metodyki czy wzorce (nawet kosztem ilości kodu) to nowy człowiek w zespole będzie miał prościej się wdrożyć i mniej czasu mu zajmie zrozumienie logiki działania całości. Nie będzie miał problemów typu, czy jak zmienię tu to gdzieś indziej mi się nie walnie. Zupełnie tak samo jak z pisaniem czytelnego kodu stosując reguły KISS/DRY i inne.

• oczywiście zgodzę się, ale to jest też plus jeśli chodzi o pozycję projektanta/programisty;)

tdoberman napisał(a):

no tak ale jeśli klient ma potrzeby takie a nie inne i jest świadomy wyboru bazy danych a jest nim Oracle - to za inne się nie biorę, a klient nie będzie za jakiś czas chciał korzystać z gorszej, bo i po co skoro się zdecydował to znaczy, że była taka potrzeba.
Tak to prawda, ale co jak masz bardzo świadomego klienta i bardzo upartego który chce aby z tylko jego znanego mu powodu system stał na danej bazie danych to moim sposobem nie będzie większego problemu. Upychając wszystko w bazie nic nie zmienisz.

wiadomo przecież, że przy bardziej wymagających zapytaniach, niestety bez full stackowego developera nie da rady;) - i takie coś realizuję, mam około 10 mln transakcji na godzinę, gdzie na podobnym sofcie za kilka milionów jest około miliona transakcji i nie nadążają z dodawaniem wirtualnych corów...;)
Pisanie zapytań na ogół nie jest trudne. A jak ma się problem idzie się do developera od baz danych i po kłopocie :)

tematyka którą się zajmuję nie wymaga takowych futerow;) - po prostu narzedzie jest dobrane do specyfikacji projektu.
Może i tak, może i nie. Akurat nie znamy dokładnej specyfiki aby tak dywagować.

ale to raczej nie stanowi problemu... oczywiście jest to znane podejście, w oraclu nazywa się to Buisness inteligence ... ale przy wymagających zapytaniach, nawet takie narzędzie nie przewyższają programisty SQL... i niestety trzeba się do niego zwrócić, bo często nie dają rady...
Nie, nie chodzi tu o BI, ale zwyczajne zestawienie np. stanów w magazynie czy zestawienie dokumentów które ma być dostępne od ręki.

• wszystko zależy od projektanta...
  Tak, wmawiaj sobie dalej. Jest takie fajne powiedzenie: "Z gówna bicza nie ukręcisz." Jak byś nie próbował zawsze to będzie mniejsza lub większa proteza.

• oczywiście zgodzę się, ale to jest też plus jeśli chodzi o pozycję projektanta/programisty;)
  Cóż, w takim razie piszmy jednolinikowce rodem z IOCCC. Wtedy pozycję masz do końca życia. Albo do czasu decyzji, że wywalą Cię bo piszesz byle jak. To jest broń obusieczna. Jak piszesz słaby kod możesz liczyć się z nieprzychylnością kolegów i wtedy masz problem.

tdoberman napisał(a):

Wszędzie tam gdzie są problemy wydajnościowe, tylko baza danych sobie może z tym poradzić i jej mechanizmy czyli Oracle;)

Owszem - wszędzie tam i tylko tam. A czy Oracle, czy inna, to jest akurat odrębny temat.

tdoberman napisał(a):

nie neguję, w końcu procedury składowane też można uznać za 3 warstwę.

Raczej nie bardzo. Trzy warstwy polegają na oddzieleniu GUI, logiki biznesowej i składowiska danych.

przy dużych projektach nie robi się takich zmian, to ma działać latami - to są fabryki, a nie blogi;)

Wiadomo, że jeśli istnieje sobie aplikacja, która ma 100 lat i ona działa, to nikt nie będzie tego przepisywał od zera na nowsze technologie, bo to nie ma sensu. Ale to nie znaczy, że działające latami aplikacje wymagają upychania logiki w bazie, bo tak nie jest.

a dlaczego wszyscy mają się zajmować wszystkim? wystarczy że są ludzie od logiki biznesowej, ludzie od bazy danych i ludzie od interfesu użytkownika? czy się mylę?;)

Przy zdrowym podejściu jest taki podział, ale przy upychaniu logiki w procedurach składowanych, SQL jest wszystkim, więc wszyscy muszą go znać na niezłym poziomie.

tak nie stosuje tych mechanizmów, ale pytanie czy bez tego da się nie żyć? i czy przy wszytkich rodzajach projektów jest to niezbędne? - raczej nie...

Oczywiście, że nie są niezbędne. Tak samo jak nie są niezbędne tablice, pętle czy instrukcje warunkowe. A jednak ułatwiają pracę i pozwalają pisać mniej kodu.

nie chodzi mi o to, że jakaś funkcja robi wszystko, chodzi mi ogólnie o to, że w tym modelu (MVC) piszesz masę kodu, który normalnie jest nie potrzebny ( w bazie )

Co to znaczy "normalnie"? Ten kod jest potrzebny aby zachować przejrzystą strukturę aplikacji z wyraźnym podziałem odpowiedzialności, zapewnić łatwość testowania oraz modyfikacji i debugowania. Kod pisze się przede wszystkim po to, aby inni ludzie mogli go czytać i modyfikować.
Ponadto, sam język pozwala Ci napisać mniej kodu niż SQL, i nawet z tym narzutem powodowanym przez MVC, finalnie jest go mniej.

tdoberman napisał(a):

tematyka którą się zajmuję nie wymaga takowych futerow;) - po prostu narzedzie jest dobrane do specyfikacji projektu.

Tematyka nie jest ważna, dzielenie kodu na funkcje i moduły to podstawa pisania czytelnego kodu, niezależnie od języka.

wszystko zależy od projektanta...

Owszem, jeśli projektant nie spieprzy na dzień dobry wpychając całej logiki do bazy, to szanse na upadek projektu maleją. To, że tak się robiło 30 lat temu, to nie jest argument, bo jakoś sporo z tych aplikacji już nie istnieje, właśnie dlatego, że nie dało się ich rozwijać.

Dobra kończymy Panowie, bo tu Fallouta trzeba ogarniać...