««« | »»»

OR Mappers: business logic e operazioni sul db

Questa serie di post sta diven­tando una saga… Come spesso capita, una volta che si ini­zia a dubi­tare, le domande fioccano. 

Di solito, una volta map­pata la tabella sulla classe poi pos­siamo imple­men­tare la cosid­detta busi­ness logic in quella classe. Spesso, però, suc­cede che que­sta busi­ness logic toc­chi più classi con­tem­po­ra­nea­mente; quindi mi sono chie­sto: non sarebbe più sem­plice con­si­de­rare quelle classi come “pas­sive” — per così dire — e imple­men­tarla com­ple­ta­mente al di fuori di esse? Nell’EOF, que­sto equi­vale a map­pare tutte le tabelle con l’EOGenericRecord o una sua sottoclasse.

Inciso: que­sto è un difetto più gene­rale dei lin­guaggi OO: devi sem­pre avere una classe o un istanza di quella classe a cui “attac­care” un metodo. So benis­simo che soli­ta­mente que­sta carat­te­ri­stica non è vista in modo nega­tivo ma sono arri­vato a un’altra con­clu­sione; ne par­le­remo un’altra volta.

Sull’altro ver­sante, quello del data­base, abbiamo tutte quelle ope­ra­zioni come le join e gli aggre­gati (SUM, AVG e così via) che sono molto più facil­mente uti­liz­za­bili diret­ta­mente a quel livello. In que­sti casi le uni­che pos­si­bi­lità sono: aggi­rare la map­pa­tura e mani­po­lare i risul­tati grezzi o defi­nire delle ulte­riori mappature.

Di solito pre­fe­ri­sco usare la prima solu­zione: la map­pa­tura non sarà com­pleta ma copre almeno i casi prin­ci­pali. La seconda appe­san­ti­sce il domain model di entità/classi con uno scopo limi­tato a casi speciali.

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