Autor Zpráva
abcOpy
Profil *
Budu vyvíjet aplikaci na správu uživatelských účtů. Tzn. admin se přihlásí a spravuje tisíce uživatelských účtů uložených např. v mysql. Doposud jsem nikdy frameworky nepoužíval. Jaký je váš názor, pro/proti použití frameworku(např. nette) pro takovou aplikaci?
denCo
Profil
Podľa mňa to je čisto na tebe. Ja osobne nikdy nepoužívam framework, radšej si to sám naprogramujem a mám nad kódom plnú kontrolu.
abcOpy
Profil *
Takový je přesně můj názor, ale vede mě k pochybám třeba nette fw, že má ošetřené prakticky všechno proti různým druhům útoků, ale zase mě dost odrazuje, že do toho přímo nevidím a může tam být nějaký bug apod.
Lamicz
Profil
IMHO jde i o to, jak je projekt rozsáhlý, co má vše "umět". Jestli je to web dělaný ve stylu naprogramuj a zapomeň, je FW zbytečný. Jestli se ale předpokládá budoucí rozšiřování, framework do toho vnáší jistou unifikaci, což se hlavně hodí pro práci v týmu.
AM_
Profil
abcOpy:
ale zase mě dost odrazuje, že do toho přímo nevidím a může tam být nějaký bug apod
K tomuto bych vznesl protiargument - omylný je každý programátor, a můj názor je, že člověk ve svém vlastním kódu naseká mnohem víc a hloupějších chyb, než je v nějakém relativně slušně napsaném frameworku, o který se třeba stará celá komunita.

Frameworky jsou podle mě výborná věc, ale aby to mělo smysl, chce to umět dobře objektové programování, mít schopnost správně dekomponovat problém a hlavně se s frameworkem naučit - což rozhodně není ke škodě, ale pokud by to bylo jen kvůli jedné aplikaci (správa uživatelských účtů není zas nic tak složitého), asi to nemá moc smyslu.
abcOpy
Profil *
AM:
správa uživatelských účtů není zas nic tak složitého
Ta aplikace nebude zas tak jednoduchá, nebude to jen obyčejné fádní spravování uživatelů. Nicméně já budu jediný vývojář a rozšiřovat se to do budoucna bude. Ale počítám s tím že si vytvořím čistý objektový návrh což mě ještě víc přivádí k nerozhodnosti použití/nepoužití frameworku. Docela by mě zajímalo kolik z vás používá na takové "kritické" aplikace frameworky a kolik ne?
AM_
Profil
v čem je ta aplikace "kritická"? pokud ale bude složitější, rozhodně bych framework nasadil, dělal jsem jeden složitý software v PHP bez frameworku a doteď toho lituji, s frameworkem by to bývalo mnohem přehlednější s 1/10 práce
mckay
Profil
abcOpy:
Ačkoliv sám zatím používám jen svůj "rádoby" framework, jsem pro to, aby jsi použil nějaký již hotový, je to bezesporu dobrá věc - ošetřené téměř vše, pravděpodobně dobrá podpora od ostatních uživatelů i dokumentace a hlavně je to povětšinou kód prověřený multi-uživatelskou praxí :).
radvis
Profil *
Já bych byl pro framework:)
dRaGen
Profil
I když by to měla bejt jednoduchá aplikace (neberu skript jako aplikaci - tedy jednorázovou činnost) ale více stránek, nějakej ten formulář tak rozhodně doporučuji nasadit framework. Už hlediska spravovatelnosti (má to logy, když se stane chyba), je to bezpečné (jeden blbě zapomenutej htmlspecialchar dělá divy) a v poslední řadě možnost přenositelnosti do budoucna + máš možnost využít pluginy a málem bych zapoměl na šablonovací systém
__construct
Profil
abcOpy:
Ale počítám s tím že si vytvořím čistý objektový návrh
Toto sa Ti pravdepodobne nepodarí - to by si musel mať viac skúseností :-)
A aby som nebol OT - osobne odporúčam používať framework, práve kvôli mnohým veciam ktoré tu už boli spomínané. Tvrdiť „zase mě dost odrazuje, že do toho přímo nevidím a může tam být nějaký bug“ je dosť odvážne - staviaš sa tým do pozície lepšieho programátora ako sú autori frameworku. Pokiaľ sa ale predsa len rozhodneš robiť si to po svojom, tak z vlastnej skúsenosti odporúčam všetko si dobre komentovať.
abcOpy
Profil *
Něco jsem početl o Nette a vypadá to že bych asi využil jen práci s formuláři, který vypadá docela dobře. Nevíte někdo jestli je potřeba data formuláře ještě nějak slashovat před vložením do db nebo jestli to všechno udělá to formulářové rozhraní Nette fw?
Alphard
Profil
abcOpy:
Nette je vhodné kombinovat třeba s dibi.
Ale jestli vážně použijete jen formuláře, lze je používat samostatně (http://doc.nette.org/cs/nette-forms).
Hlavní výhoda frameworku je v tom, že vám usnadní návrh databáze, tj. v případě Nette MVP struktura. Samozřejmě se to ale nejdřív musíte naučit a přistoupit na filozofii fw, který si vyberete.
Majkl578
Profil
abcOpy:
Použití frameworku má mnoho výhod, které rozhodně převažují nad nevýhodami.
Já už přes rok pracuji s Nette Frameworkem a troufám si říct, že svou kvalitní implementací MVP návrhu značně usnadňuje vývoj. Když přidám aktivní českou komunitu (fórum, jabber - realtime řešení problému), brzy novou dokumentaci (momentálně ji píšeme), má začátečník (pozor, ne s objektovým programováním, ale s frameworkem!) otevřené dveře.

Alphard:
Nette je vhodné kombinovat třeba s dibi.
Asi jedinou výhodou použití dibi v Nette je profiler v Debug Baru. Jinak je naprosto jedno co člověk použije, klidně čisté MySQLi. Já třeba aktuálně používám Doctrine 2.

radvis:
Bohužel.
AM_
Profil
abcOpy:
Nevíte někdo jestli je potřeba data formuláře ještě nějak slashovat před vložením do db nebo jestli to všechno udělá to formulářové rozhraní Nette fw?
Oescapování dat je otázka databázové vrstvy a nikoli formuláře. Takže Nette\Forms se o escapování pro databázi nestará (každé datové úložiště může vyžadovat jiné escapování).

Majkl578:
Asi jedinou výhodou použití dibi v Nette je profiler v Debug Baru.
Mě se docela dost líbí automatické "escapování", a to jak pro různé verze SQL (použije se jednotný syntax dibi a driver pro danou DB si to už oescapuje), tak i rozvinutí některých složitějších struktur (např. %v expanduje asociativní pole na jinak těžkopádně sestavitelné (sloupec,sloupec,sloupec) VALUES (hodnota,hodnota,hodnota)
//jinak celkově k Dibi: přijde mi v něčem dost nedotažená, narozdíl od robustního nette je to spíše opravdu taková intimní vložka mezi programátora a nepohodlnou syntaxi SQL, ale pro jednoduché věci je skvělá a jednoduchá a pro složitější se vyplatí použít nějaký propracovaný ORM.
Majkl578
Profil
[#15] AM:
To je ovšem argument pro použití dibi, nikoliv dibi v Nette. :) Doctrine to dělá taky, troufnu si říct, že dobrý DBAL by to uměl měl.
abcOpy
Profil *
Mě se syntaxe SQL líbí a nemám moc rád různé vychytávky typu $db->select(neco)->from(neco).
Alphard
Profil
abcOpy:
To se mi také nelíbí, ale knihovna může ulehčit např. escapování vkládaných hodnot.
$vysledek = dibi::fetchAll("select [name] from [jmeno_tabulky] where [id] = %d", $_GET['id']);
V $vysledek už je výsledek jako pole. Dotaz je naprosto bezpečený, nic víc není potřeba řešit.
Když jste ve vývojářském módu, tak se vám posílají vygenerované dotazy, čas, explain, případně chyby, aniž byste musel dopisovat mysql_error() a cokoliv podobného.
abcOpy
Profil *
Dá se dibi provozovat v čistě objektovém přístupu(potřebuju několik připojení k různým databázím, ale jen v části aplikace)? V těch manuálech jsem viděl jen přístup přes třídu(dibi::) nebo kombinaci.
Alphard
Profil
Jde to
$connection = new DibiConnection($options);
$connection->query('TRUNCATE `table`');
Ale myslím, že mezi databázemi lze přepínat i statickým voláním.
abcOpy
Profil *
A co chybové výstupy? Kdybych chtěl zjistit zda nedošlo v posledním dotazu k chybě, příp. vypsat číslo a text chyby.
Alphard
Profil
Dobrý pomocník je http://dibiphp.com/cs/profiler-a-propojeni-na-firebug.
Více informací na http://doc.nette.org/cs/nette-debug-firebug.
abcOpy
Profil *
To jsem četl, mě jde ale o chybové zprávy vypisované přímo v php aplikaci přímo uživatelům ty aplikace.
AM_
Profil
abcOpy:
Mě se syntaxe SQL líbí a nemám moc rád různé vychytávky typu $db->select(neco)->from(neco).
Tohle je jen "syntactic sugar" - někdo to má rád a používá, žádná technická výhoda v tom není.
Co se týče syntaxe tak je hezky human-readable, ale blbě se tvoří strojově (hlavně složitější dotazy), což dibi částečně usnadňuje.

[#16] Majkl578
jasně, s tím souhlasím - jak jsem říkal, dibi je jednoduchá a pouze se základními vychytávkami, které samozřejmě větší DBAL mají.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0