”You’re damned if you do, and you’re damned if you don’t”
- Lorenzo Dow

Java och webutveckling landar förr eller senare i användandet av ett eller flera (med betoning på flera) tredjepartsramverk – inte sällan i form av Open source-projekt.

Ramverken hjälper oss mappa relationsdatabaser mot Java-objekt (Hibernate m.fl.), de hjälper oss bygga bort Servlets och jsp-sidor (Struts, Struts2, JSF…), de hjälper oss med presentation (Tapestry, Facelets, Velocity, FreeMarker…) och de hjälper oss med automattestning (Mockito, JUnit, PowerMock etc.).

Vi ska med detta uppnå en kliniskt vacker MVC-struktur i koden. Allt ”onödigt” ska gömmas undan. Det mesta ska se per automatik. Här ska inte skrivas någon HTML eller SQL, sånt som utvecklarna inte tycker om. Request-parametrar ska flyga in på magiskt vis, SQL:er ska bakas bakom kulisserna. Allt för att utvecklaren ska kunna fokusera på den ack så heliga Affärslogiken. Affärslogiken som dessutom kommer hamna på EXAKT rätt ställe i arkitekturen då de tvingande ramverken i princip omöjliggör att kod skrivs i fel lager.

Syftet är helt klockrent – där är jag en av de sista att opponera mig – MEN…

Ramverken har ett pris.

Hur mycket tid har du spenderat på att medelst skohorn klämma in ”Ramverk X version 3.0.6GA” i din applikation som redan kör ”Ramverk Y”, ”Z” och ”ÅÅ”? En applikation som dessutom kryddats med ”hemmasnickrat lokaliseringssystem version nix pix” och ”företagsspecifik standard för att komma runt den där gamla Oraclebuggen”?

Bränt ett par timmar på att googla efter hur man kan lösa ”Problem 4B” med nämnda ”Ramverk Y” ?

Upptäckt att ”Ramverk ÅÅ” kräver att du uppgraderar din risiga gamla applikationsserverversion och dessutom patchar Hibernate-cachen?

Kommit fram till att GWT och JSF kräver rejäla omtänk beträffande arkitektur och kodning?

På konferenser och på Open source-projektens hemsidor brukar vi, när det gäller webutveckling, alltid få stifta bekantskap med en och samma sak när vi ska ”get started”:

”En Enkel Webshop”

Återigen är jag inte sen att hålla med. Ska vi bygga En Enkel Webshop är de flesta ramverken en gudagåva. (Det går förstås utmärkt att bygga en enkel webshop med en Accessdatabas, några HTML-formulär och ett par Perl-script, men ändå.)

Om webshoppen å andra sidan har ett par år på nacken, ett tight beroende till en trubbig databas, integration mot några sköna Bill Gates-system samt en eller två generationer av legacykod brukar det bli jobbigare.

Du får helt enkelt väldigt sällan chansen att skriva något från scratch. Du får än mer sällan tiden från din beställare att försöka mecka in det där coola ramverket som NetBeans (Förresten, vilken icke-SUN-anställd använder egentligen NetBeans?) hade så mäktigt drag-and-drop-stöd för.

Jag är övertygad om att det går att göra ”hemmahackade” webapplikationer förvaltningsbara. Att via smart design slippa sitta med den ökända lerbollen droppandes i knät. Lägg tiden på att koda ihop ett specialiserat lättviktsramverk som löser DINA problem istället för att lägga dubbelt så mycket tid på att patcha källkoden till Struts2 för att passa er lik förbannat hemmahackade internationaliseringslösning.

HTML är fortfarande bästa sättet att skriva HTML-formulär. SQL är väl lämpat att fråga databasen efter data, och nog fan kommer du sitta där med en Servlet i slutändan när allt kommer till kritan?

(Brasklappen i allt detta bakåtsträvande är här att jag många gånger nära nog gråtit av lycka över vissa features hos FreeMarker, JSTL, Struts2, Hibernate, Facelets och Mockito. Samt svurit över 3000-raders-Servlets.)

Jesper Hasselström