2009/6/23 Lasse Munk <[address removed]>:
> Jeg synes mange af de sp?rgsm?l der stilles herinde er gode, men de tyder
> ogs? p? at folk ikke benytter et framework? Selvom der har v?ret en del snak
> om, hvilket framework man skulle v?lge, s? tyder det alligevel p? at mange
> ikke er overbevist?

Godt sp?rgsm?l (eller hvad man nu skal kalde det). Jeg tror der er
flere svar p? det. Jeg kan pr?ve at give et par stykker.

Det korte svar er, at det g?r mange af os skam ogs?. Jeg ved at der er
flere her i gruppen, der bruger Symfony eller Drupal, og jeg selv
bruger ogs? et web framework p? daglig basis, omend det lige for tiden
ikke er PHP (Jeg arbejder med Rails).

Et lidt mindre klart svar kunne v?re med et mod-sp?rgsm?l: Hvordan
definerer du begrebet framework? Er Zend Framework et framework? Er
PEAR et framework? Er Drupal et framework? Er PHP et framework?
Afh?ngigt af svaret, bruger vi alle sammen et framework.

Hvis vi ignorerer ovenst?ende, kan vi m?ske blive enige om at der i
praksis findes en offentlig bevidsthed om hvad et framework er, selvom
det ikke kan defineres absolut. Et s?dant begreb syntes at d?kke over
et library af t?t koblede komponenter, der dels varetager mapningen
mellem http request, handler og response (popul?rt kaldet controller
laget), dels stiller nogle redskaber til r?dighed for rendering af
html (view laget) og dels indeholder et orm. Hvis vi kan blive enige
om dette udgangspunkt, s? er der en r?kke grunde til at jeg forholder
mig skeptisk (omend ikke komplet afvisende) overfor konceptet.

Den vigtigste anke jeg har, er at frameworks er t?t koblede. Det er
muligt at de er internt l?st sammensatte, men n?sten uden undtagelse,
er de meget sv?re at integrere med anden kode. Det er et praktisk
problem, hvis man eks. allerede har en masse kode og ikke har lyst til
et k?mpe rewrite, eller hvis man bare har tredieparts komponenter, men
det er ogs? et lidt mere filosofisk problem; En t?t koblet stak - som
eks. Symfony - opstiller nogle meget klare regler for hvad der er god
skik og hvad der ikke er. Hvis vi accepterer det postulat at Symfony
ikke er et udtryk for den teknologiske singularitet, s? m? deraf f?lge
at der er visse ting (m?ske blot i bestemte sammenh?nge), hvor disse
regler er suboptimale. I et ?bent system, ville man kunne v?lge disse
komponenter fra, men det er meget sv?rt at g?re i et t?t koblet
system. Eks. er de fleste frameworks bygget op omkring et orm. Hvis
din applikation ikke egner sig til at bruge orm, eller hvis backenden
slet ikke er database-drevet, s? st?r du overfor Valby bakke i femte
gear. Et m?ske endnu bedre eksempel er Frontcontroller+MVC paradigmet.
Jeg er ikke enig i at det altid er den bedste m?de at organisere en
web applikation p?, men hvis jeg bruger et framework, s? bliver jeg
tvunget til at f?lge trop.

Kort sagt, kan man sige at problemet med frameworks er at deres
bureaukrati hindrer kreativitet, og kreativitet er en foruds?tning for
at skrive god software. Den anden side af sagen er s? selvf?lgelig, at
det ogs? hindrer d?rlig kreativitet, s? de fungerer p? den m?de som et
sikkerhedsnet imod d?rlige programm?rer (eller lad os kalde det "gode
programm?rer, der har en d?rlig dag", som nok meget oftere er
tilf?ldet). Kreativitet kan ogs? v?re et problem i store grupper, hvor
der simpelthen ikke er plads til at alle udfolder sig frit. Her kan et
framework virke som en m?de at kontrollere gruppedynamikken p?.

S? min holdning er at frameworks repr?senterer et tradeoff mellem
dynamik (det man mister) og stabilitet (det man f?r). Der er bestemt
situationer (mange endda), hvor det tradeoff er en nettogevinst, men
det er naivt at tro at den er gratis.

> Og hvor mange af jer kan sige at den sidste app i lavede, var 100% beskyttet
> mod Injection og XSS attacks, havde caching, validering af alle forms, var

Sikkerhed er aldrig 100%

--
troels