Vlákno názorů k článku PL/Perl, PostgreSQL (2) aneb jak na aplikační server od anonym - Aplikacni server v databazove vrstve je imho vec...
-
Neni to vytrzeno z relity. To existuje (napadaji mne dve takove Oracle aplikace), a rekl bych ze tak casem dopadne i kazda dvouvrstva aplikace, ktera se trosku rozroste a autori podlehnou kouzlu schopnosti DB:-) Dulezite je davat si pozor, protoze hranice prorustani logiky a ulozeni dat je pro radu autoru software dost ruzna.
Ostatne negativa jsou v clanku naznacena. -
Zaleží co potřebujete dělat. Pokud je Vaše aplikace data centrická, tak pak tak úplně mimo není. To, že mohu použít libovolný jazyk uložených procedur je těžká výhoda. Kód je kratší, přehlednější. Alespoň pro mne. Už jsem se dostal do stavu, kdy externí jazyky používám snad jen pro spuštění uložené procedury a prezentaci výsledků. Nemohu si pomoct, kód v PL/pgSQL je podstatně čtivější. Víc mi šlo ale o prezentaci filozofie, že na každou vrstvu lze chápat ne jako sadu procedur, ale jako sadu aplikací. Je to trošinku něco jiného -
anonymníJakmile umistite cast business vrstvy do aplikace, pak se aplikace stava zavisla na vendorovi databaze a o co se "zjednodusi" business vrstva, o to se stane slozitejsi samotna databaze. Ma to smysl u mensich projektu, avsak u projektu velkych je to dlouhodobe neudrzitelne. Databazi chapu pouze jako persistentni uloziste dat (logiku piseme v Jave a je umistena ve vrstvach dle patternu Application Service a Business Object, Enterprise Java Beans). Pak muzeme pouzit defacto jakoukoli databazi. :)
-
Proc ne. Je to taky jeden z trendu. Priznam se, ze nerozumim, proc by preneseni casti logiky do databaze bylo dlouhodobe neudrzitelne. Zatim jsem neslysel jediny argument! Cim se lisi kod procedury v PL nebo v Jave? V PL nemam objekty, ale zas mam integrovane SQL. Pokud pisi aplikacni logiku v Jave, nebo v MTS, tak fakt nejsem zavisly na RDBMS. Potrebuji jedine, rychle serializovat a deserializovat objekty. Nic vic. Jenomze: stanu se zavislym na Jave, MTS, atd; pristup k datum mam o jednu uroven vys. Zavislost na Jave nebo zavislost na PostgreSQL nebo MsSQL, Oracle neni argument. Technologicka zavislost proste existuje u vsech aplikaci. To, ze musim do DB skrz dalsi vrstvu uz argument je. Mozna mam jen par negativnich zkusenosti s nekolika projekty, kdy bylo prakticky nemozne se dostat k vlastnim datum v databazi: protoze dodavatel zakazal jakykoliv primy pristup do db, protoza data byla ulozena v nestandardnim formatu v databazi. Jakykoliv import, export dat byl vylouceny, pokud si uzivatel nazaplatil za zvlastni importni, exportni programy. Mozna optimalni je kompromis: silna db vrstva, silna aplikacni, a to i za cenu rizika, ze nektere casti budu programovat dvakrat (ackoliv to je klasicka technika, jak bezpecny sw).
ČLÁNKY DO MAILU