Una volta c'erano i POJO:
Il mondo Java si è scottato non poco con l'avvento degli EJB fino alla versione 2, che rappresentavano effettivamente un esempio di cattivo design che non favoriva tra l'altro isolamento e testabilità. Classi cioè che per vivere avevano la necessità di implementare interfacce per risolvere problemi di infrastruttura e non applicativi.
Fortunatamente si sono rinsaviti, adesso le specifiche EJB 3 si basano su modelli POJO cioè "plain old java object".
Classi che non hanno più costrizioni particolari per il funzionamento in contesti enterprise.
Nel mondo .NET, un problema di design simile non c'è stato, si è però cmq diffusa la terminologia POCO,
corrispettivo di "Plain Old C-sharp Object" o sarebbe meglio dire "Plain Old CLR Object",
così quelli di vb.net non ci rimangono male.
E uno si chiede...ma perchè la terminologia POCO in .NET? Mica il disastro EJB 2 è passato pure da noi...
ed effettivamente c'è stato un periodo in cui anche io stesso non volevo utilizzare quel tipo di nomenclatura.
Ma se ci si concentra sui veri principio dei POJO, si arriva ad una conclusione diversa:
1. Non hanno necessità di ereditare da nessuna classe base
2. Non devono implementare nessun tipo di interfaccia
3. Non hanno bisogno di factory per essere costruite
4. Non hanno bisogno di costruttori specifici per essere costruite
5. Non hanno nessuna logica interna per la persistenza
Un POCO non è semplicemente una classe che non deve implementare interfacce o eredirare da qualche tipo specifico, per funzionare correttamente in ambienti enterprise.
E' invece la massima espressione di libertà progettuale, formalizzata da quelle 5 regole.
Quindi POCO ha senso di esistere eccome, come principio di modellazione.
NHibernate e Linq 2 SQL sono due ORM che lavorano (piò o meno) con oggetti POCO.
Nell'uscita di Entity Framework June CTP di poche ore fa, nel post ho notato la presenza di un termine nuovo (per me): IPOCO.
Come espresso più volte da persone dal team, Entity Framework non era, prima di questo rilascio, considerato un ORM perfettamente trasparente poichè aveva la necessità di lavorare con delle entity che dovevano ereditare da una Base specifica. Questa CTP invece, fa un passo avanti e ci lascia l'ereditarietà libera, dando come unico vincolo l'implementazione di una interfaccia IEntity (o giù di li).
Forse non c'era bisogno di inventare una nuova terminologia IPOCO.
Bastava dire che EF non lavora tutto'ora con classi POCO (non rispetta la regola2)...
Ma questo rappresenta cmq un passo in avanti rispetto a prima (con un paio di soluzioni a base di mixin e AOP si può evitare/raggirare questa costrizione).
Mi sa che questa CTP non la installo, in attesa dell'eventuale Beta 2 di Orcas (se non ho capito male EF sarà cmq presente nella Beta anche se non verrà rilasciato in RTM)
** Qualcuno si sta chiedendo cosa sia MOJO?
E' semplicemente il nome del cagnolino che in pratica ha recitato meglio di tutti nel film categorizzato come miglior "Bufala del quinquennio" alias: Transfomers....
So che Andrea, Ugo e Laura saranno d'accordo con me.
L'unico motivo per cui sono rimasto in sala era: mora, capelli lunghi e occhi verdi.