Spring 3 ja @nnotaatiot

Spring 3 on julkaistu ja hyrrännyt jo hetken aikaa palvelimissa. Spring 3 ei mullistanut mitään merkittävää useimpien osalta mutta vakiinnutti jo Spring 2 ja 2.5 versioissa tulleet toimintatavat – monet vanhat Spring rajapinnat ovat nyt joko poistettuja tai deprekoituneiksi merkattuja, ja niitä ei enää voi tai ole syytä käyttää.

Mielenkiintoinen kehityssuunta on, että kun 2000-luvun taitteessa XML oli uusi hype ja sitä käytettiin kaikkeen EJB komponenttien ja web moduulien konfiguroinnista Spring tyyppiseen liimaan olioiden välissä, nyttemmin xml on alettu näkemään pahana asiana ja siitä yritetään hankkiutua eroon yhtä tarmokkaasti annotaatioilla.

Tähän väliin maistiainen hello world tasoisesta uudesta Spring controllerista joka vastaa vanhaa Form Controlleria:

@Controller
@RequestMapping(value=”/feedback”)
public class FeedBackController  {

  // content goes here, any methods for handling /feedback

}

EJB 3 kohdalla annotaatiot ovat aivan upea asia, ja sama on nyt Java EE 6 alustalla ulotettu myös web komponentteihin. Spring Frameworkissä taas oli upea asia, että osa konfiguraatioista saatiin nimenomana ulos koodista, siten että jos niitä muuttaa, ei tarvitse kääntää ja paketoida koodia, vaan muutos voidaan tehdä tarvittaessa kevyenä ylläpitotoimena vaikka tekstieditorilla. Nyt uusissa Spring malleissa on lähdetty korvaamaan lähes kaikki XML annotaatioilla ja monipuolisuuden viidakossa homma monimutkaistuu.

Spring 3.0 deprekoi mm. SimpleFormController luokan, jonka varaan aiemmin oli tehty paljonkin ratkaisuja. Deprekoitunut osa on suuressa vaarassa tipahtaa esim. Spring päivityksessä 3.1, 3.5, 4.0 tms.. On siis aika riskialtista käytellä sitä enää koodauksessa, olisi syytä siirtyä @Controller annotaatioon ja uuteen @MVC malliin.

Tässä esimerkkiä @Controller luokan metodeista jotka tekevät saman mitä vanha SimpleFormController:

@RequestMapping(method=RequestMethod.GET)
 public ModelAndView showForm() {
     FeedbackCommand command = new FeedbackCommand();
     ModelAndView mav = new ModelAndView(”feedbackform”,”feedbackCommand”,command);
     return mav;
 }

@RequestMapping(method=RequestMethod.POST)
public ModelAndView onSubmit(
    @Valid @ModelAttribute(”feedbackCommand”) FeedbackCommand command,
    BindingResult result)   throws Exception {
     if (result.getErrorCount() > 0) {
        ModelAndView mav = new ModelAndView(
              ”feedbackform”,”feedbackCommand”,command);
        return mav;
     }
     System.out.println(”bindingresult:” + result);
     System.out.println(”command:” + command);
     System.out.println(”errorcount: ” + result.getErrorCount());
     ModelAndView mav = new ModelAndView(
            ”feedbacksubmit”,”feedback”,command);
     return mav;
   }

Ei siinä mitään, @Controller on hieno annotaatio ja tekee paljonkin.. Mutta kun siihen yhdistää lomakekäsittelyä ja validointia, alkaa olemaan aikamoista annotaatiohuttua koko koodi. Eikä siinä mitään, mutta kun eri parametreja ja paluuarvoja käsittelymetodeille on n. 20, ja niiden eri kombinaatioita on tuhansittain, alkaa olemaan vaikeaa löytää taas hyviä esimerkkejä, tai lukea toisen koodaajan tekemää koodia. Joustavuudesta kymppi, selkeydestä kuusi puoli tämän muutoksen osalta.

Osa esimerkeistä käyttää uutta Java EE 6 Bean Validation rajapintaa. En ole vielä päättänyt pidänkö siitä vai inhoanko sitä. On ihan metkaa että voi viimeinkin upottaa suoraan bean ominaisuuksiin tiedon siitä mikä voi olla null tai minkä maksimipituus on 50 merkkiä. Mutta mitä jos tämä ei olekaan absoluuttinen totuus, vaan vaihtuu? Joissakin projekteissa on parasta upottaa nämä beaniin, joskus taas on parasta irrottaa Validation osuus erilleen erikseen päivitettäväksi. Hyvä puoli on että Spring antaa mahdollisuuden tehdä tämä valinta. Huono uutinen on se että valintojen myötä monimutkaisuus uhkaa kasvaa ja toimintavarmuus heiketä.

Ironista on, että Spring aikanaan kehitettiin ratkaisemaan silloisen EJB mallin puutteita, hurjaa monimutkaisuutta ja sitä myöten heikkoa toimintavarmuutta. Spring mallin oli tarkoitus olla selkeä yksi malli, yksinkertainen ydin jonka varaan voidaan rakentaa monimutkaisia toimintoja helposti ja varmasti. Kestääkö nykyinen soppa tarkastelun? Se selvinnee parin vuoden sisään. Hyvä puoli on sentään että alustasta on deprekoitu ja poistettu ronskisti vanhentuneita piirteitä, toisin kuin virallisista Java-standardeista.

Kannattaa siis olla varuillaan annotaatioiden kanssa ja miettiä mihin ne ovat hyviä ja mihin ei. Vallalla on samantapainen annotaatiohurmos kuin aikanaan XML:n kanssa. Molemmilla on edelleen omat hyvät paikkansa ja puolensa, ja omat heikkoutensa. Spring 3:sen kanssa menee vielä opetellessa aikansa, ja valintoja on edessä entistä enemmän. Mielenkiintoiselta päivitys toki vaikuttaa, ja jahka pääsen tekemään Groovyllä spring konfiguraatioita… 😉

Mainokset

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s