««« | »»»

OR Mappers: i primi dubbi

A dispetto dei “great blun­ders” (1, 2), per un certo tempo ho tenuto la vocina cri­tica oppor­tu­na­mente al di sotto della soglia udi­tiva; mi sem­bra­vano que­stioni mar­gi­nali e comun­que lavo­rare con l’EOF era diver­tente ed ele­gante, soprat­tutto rispetto a pro­dotti ana­lo­ghi, come Hibernate.

Infatti, ho comin­ciato ad avere qual­che dub­bio serio su que­stioni che non riguar­dano diret­ta­mente la scor­retta ana­lo­gia classe-tabella. Semplicemente, un giorno ho comin­ciato a chie­dermi se, al posto di map­pare il nome del cliente da VARCHAR a String, non sarebbe stato meglio defi­nire una classe ad hoc.

In fondo — mi dicevo — che senso ha scri­vere una cosa del tipo cliente.nome().equals(indirizzo.via()), visto il loro signi­fi­cato è com­ple­ta­mente diverso? È vero, di solito usiamo String per entrambi i valori e anche gli even­tuali vin­coli d’integrità potreb­bero essere molto simili, ma non ha molto senso con­fron­tare un nome con una via.

Purtroppo, per quanto l’idea sia cor­retta, la com­ples­sità del codice schizza alle stelle per­ché non è sem­plice imple­men­tare la cosid­detta “spe­cia­li­za­tion by con­straint”; con l’EOF, in Java, non sono riu­scito a otte­nere risul­tati decenti.

E così ho comin­ciato a ripen­sare il mio approccio.

Per proseguire

Commenti e trackback sono disabilitati.

• Tweets, 2012-02-05
• Tweets, 2012-01-29
• Tweets, 2012-01-22
• Tweets, 2012-01-15
• Tweets, 2012-01-08