Massimi Sistem - parte II (sottotitolo OR/M + IoC)

Buongiorno a tutti,

volevo chiedervi qualche consiglio:

1. avreste da consigliarmi qualche buon motore di IoC (perché a mano non ce la faccio più)?

2. avreste da linkarmi a qualche applicazione che illustri come "sposare" un motore di IoC con un domain model generato da un OR/M?

3. come incastrare tutto questo in un pattern MVC/P?

Ciao e grazie,

Giulio

 

p.s. ma... l'interfaccia NNTP? Defunse?

--

 

Ciao petrux,

You wrote on 19/10/2009 :
> Buongiorno a tutti,
>
> volevo chiedervi qualche consiglio:
>
> 1. avreste da consigliarmi qualche buon motore di IoC (perché a mano non ce
> la faccio più)?

benvenuto :-)

Io uso Castle Windsor, si parla moltissimo benissimo anche di
Spring.Net.

> 2. avreste da linkarmi a qualche applicazione che illustri come "sposare" un
> motore di IoC con un domain model generato da un OR/M?

dettagli un po' meglio il problema perch� cos� non riesco a capire cosa
ti serva fare


> 3. come incastrare tutto questo in un pattern MVC/P?

con molta attenzione e metodo :-) non c'� molto da incastrare bisogna
prima aver ben chiaro cosa sono IoC e DI senza un motore di dependency
injection.

io la vedo cos�:
http://blogs.ugidotnet.org/topics/archive/0001/01/01/abuso-di-inversion-of-control-il-container-questo-sconosciutohellip-e.aspx

> p.s. ma... l'interfaccia NNTP? Defunse?

Io ti sto rispondendo da li... ma va decisamente a singhiozzo, ci
stiamo lavorando.

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

> 2. avreste da linkarmi a qualche applicazione che illustri come "sposare" un
> motore di IoC con un domain model generato da un OR/M?

dettagli un po' meglio il problema perch� cos� non riesco a capire cosa
ti serva fare

In estrema sintesi, ti butto nel mucchio i miei dubbi amletici (ed anche un po' atavici).

- Il modello generato dall'O/RM va reso accessibile dal motore di IoC?

- supponi che abbia una classe Foo che ha come membro una lista di Bar:

class Foo {

    IList<Bar> BarList { get; }

}

class Bar {

    int Seed { get; set; }

}

Ora, supponi che li cliente A voglia che ogni Foo possa tenere al massimo 3 Bar, mentre il cliente B vuole che un Foo possa avere solo Bar con Seed pari a un numero dispari. Ammesso (e lo ammetto :-)) che queste regole di business siano implementate (appunto) a livello di business logic layer. Come mi viene in aiuto l'IoC nell'ottioca di evitare di mantenere due linee di prodotto differenti? :-)

> p.s. ma... l'interfaccia NNTP? Defunse?

Io ti sto rispondendo da li... ma va decisamente a singhiozzo, ci
stiamo lavorando.

Ma da che server?

Io proprio non riesco a connettermi... :-/

 

Ciao,

Giulio

Ciao Giulio,

You wrote on 19/10/2009 :
>> 2. avreste da linkarmi a qualche applicazione che illustri come "sposare" un
>> motore di IoC con un domain model generato da un OR/M?
> In estrema sintesi, ti butto nel mucchio i miei dubbi amletici (ed anche un
> po' atavici).
>
> - Il modello generato dall'O/RM va reso accessibile dal motore di IoC?

No, secondo me il modello di dominio non ha nulla a che spartire con
IoC � il modello di dominio e deve poter vivere di vita propria

> - supponi che abbia una classe Foo che ha come membro una lista di Bar:
>
> class Foo {
>
> IList BarList { get; }
>
> }
>
> class Bar {
>
> int Seed { get; set; }
>
> }
>
> Ora, supponi che li cliente A voglia che ogni Foo possa tenere al massimo 3
> Bar, mentre il cliente B vuole che un Foo possa avere solo Bar con Seed pari
> a un numero dispari. Ammesso (e lo ammetto :-)) che queste regole di business
> siano implementate (appunto) a livello di business logic layer. Come mi viene
> in aiuto l'IoC nell'ottioca di evitare di mantenere due linee di prodotto
> differenti? :-)
>

non ti viene in aiuto, probabilmente questi constraint hanno senso a
livello, ad esempio, di "mapping" tra il tuo modello e lo storage,
oppure sono regole di business di un ipotetico "validator" che valida
l'entity allora si quel validator viene iniettato nel mondo
(probabilmente in un repository) tramite IoC/DI

> Ma da che server?
>

www.guisa.org

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> No, secondo me il modello di dominio non ha nulla a che spartire con
> IoC � il modello di dominio e deve poter vivere di vita propria

Ok, got it.

> non ti viene in aiuto, probabilmente questi constraint hanno senso a
> livello, ad esempio, di "mapping" tra il tuo modello e lo storage,
> oppure sono regole di business di un ipotetico "validator" che valida
> l'entity allora si quel validator viene iniettato nel mondo
> (probabilmente in un repository) tramite IoC/DI

Uhm... andiamo per approssimazioni successive... :-)
1. constraints tra il modello e lo storage: le domande sono: *chi* e
*quando* esegue il controllo?
2. validator: questa ipotesi mi piace assai. :-) Però rimane sempre il
problema di *dove* viene iniettato. Se io infatti penso di fare una cosa
tipo:

class Foo {
public Foo(IFooValidator validator)
{ }
...
}

di fatto introduco una dipendenza tra il modello di dominio e il resto
(e quindi il modello di dominio non vivrebbe più di vita propria). Se
invece - come giustamente fai notare - il validator va iniettato nel
repository, la domanda a questo punto è: da dove viene preso il
repository? E' per caso (new MyDomainModel()).FooList? (spero che
l'esempio sia chiaro).

Ciao e grazie,
Giulio

p.s.: pare che anche qui l'interfaccia NNTP abbia ripreso a
funzionare... :-)
--

Ciao petrux,

You wrote on 19/10/2009 :
> Uhm... andiamo per approssimazioni successive... :-)
> 1. constraints tra il modello e lo storage: le domande sono: *chi* e
> *quando* esegue il controllo?

Se ad esempio usi un O/RM lo puoi far fare a lui.

> 2. validator: questa ipotesi mi piace assai. :-) Però rimane sempre il
> problema di *dove* viene iniettato. Se io infatti penso di fare una cosa
> tipo:
>
> class Foo {
> public Foo(IFooValidator validator)
> { }
> ...
> }
>
> di fatto introduco una dipendenza tra il modello di dominio e il resto
> (e quindi il modello di dominio non vivrebbe più di vita propria). Se
> invece - come giustamente fai notare - il validator va iniettato nel
> repository, la domanda a questo punto è: da dove viene preso il
> repository? E' per caso (new MyDomainModel()).FooList? (spero che
> l'esempio sia chiaro).
>

DI :-)

class MyEntityPresenter : IPresenter
{
public MyEntityPresenter( IRepository repository,
IValidator validator )
{

}
}

ma anche:

class MyEntityRepository : IRepository
{
public MyEntityRepository( IValidator validator )
{
}
}

in questo modo il repository pu� rifare la validazione partendo dal
presupposto che non si deve fidare di nessuno :-)

In uno scenario reale fare le cose un po' pi� articolate.

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> > Uhm... andiamo per approssimazioni successive... :-)
> > 1. constraints tra il modello e lo storage: le domande sono: *chi* e
> > *quando* esegue il controllo?
>
> Se ad esempio usi un O/RM lo puoi far fare a lui.

Uhm... scusa se mi "allargo" ma... potresti farmi un esempio?

> > 2. validator: questa ipotesi mi piace assai. :-) Però rimane sempre il
> > problema di *dove* viene iniettato. Se io infatti penso di fare una cosa
> [cut]
> DI :-)
>
> class MyEntityPresenter : IPresenter
> {
> public MyEntityPresenter( IRepository repository,
> IValidator validator )
> {
>
> }
> }
>
> ma anche:
>
> class MyEntityRepository : IRepository
> {
> public MyEntityRepository( IValidator validator )
> {
> }
> }
>
> in questo modo il repository pu� rifare la validazione partendo dal
> presupposto che non si deve fidare di nessuno :-)

Ok, fin qui ci siamo. Questo però implica che la validazione viene fatta
(per quanto riguarda il "chi") non dall'entità Foo stessa ma dal
repository. Per quanto riguarda il "quando" invece, credo che venga
fatta solo al salvataggio dei dati. Ora, non sarebbe più comodo che (ad
esempio, se il Bar deve avere seed solo dispari) in una situazione del tipo:

Foo foo = new Foo();
Bar bar = new Bar()
{
Seed = 12
};
foo.BarList.Add(bar); // --> eccezione!!!

che l'ultimo statement sollevasse un'eccezione?

> In uno scenario reale fare le cose un po' pi� articolate.

uh?

Ciao e grazie,
Giulio
--

Ciao Giulio,

You wrote on 20/10/2009 :
>> Se ad esempio usi un O/RM lo puoi far fare a lui.
>
> Uhm... scusa se mi "allargo" ma... potresti farmi un esempio?

usando ad esempio NHibernate ti puoi inserire nella pipeline della
ISession e li fare pressochè tutto in maniera trasparente.

>>> 2. validator: questa ipotesi mi piace assai. :-) Però rimane sempre il
>>> problema di *dove* viene iniettato. Se io infatti penso di fare una cosa
>> [cut]
>> DI :-)
>>
>> class MyEntityPresenter : IPresenter
>> {
>> public MyEntityPresenter( IRepository repository,
>> IValidator validator )
>> {
>>
>> }
>> }
>>
>> ma anche:
>>
>> class MyEntityRepository : IRepository
>> {
>> public MyEntityRepository( IValidator validator )
>> {
>> }
>> }
>>
>> in questo modo il repository pu� rifare la validazione partendo dal
>> presupposto che non si deve fidare di nessuno :-)
>
> Ok, fin qui ci siamo. Questo però implica che la validazione viene fatta
> (per quanto riguarda il "chi") non dall'entità Foo stessa ma dal
> repository. Per quanto riguarda il "quando" invece, credo che venga
> fatta solo al salvataggio dei dati. Ora, non sarebbe più comodo che (ad
> esempio, se il Bar deve avere seed solo dispari) in una situazione del tipo:
>
> Foo foo = new Foo();
> Bar bar = new Bar()
> {
> Seed = 12
> };
> foo.BarList.Add(bar); // --> eccezione!!!

si ma se questa logica deve essere configurabile la vedo un po' dura

> che l'ultimo statement sollevasse un'eccezione?
>
>> In uno scenario reale fare le cose un po' pi� articolate.
>
> uh?

pensavo al motore di IoC e all'esempio dei repository che ha molto poco
di real-life, nulla di più. Nella vita reale la modellazione di uno
strato di business è decisamente più complessa.

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> usando ad esempio NHibernate ti puoi inserire nella pipeline della
> ISession e li fare pressoché tutto in maniera trasparente.

Uhm... ma così non si crea una dipendenza Modello --> Applicazione?

> si ma se questa logica deve essere configurabile la vedo un po' dura

Anche io! :-)

> pensavo al motore di IoC e all'esempio dei repository che ha molto poco
> di real-life, nulla di più. Nella vita reale la modellazione di uno
> strato di business è decisamente più complessa.

...e torniamo alla domanda iniziale: qualche esempio?
:-)

Ciao e grazie,
Giulio
--

Ciao Giulio,

You wrote on 23/10/2009 :
>> usando ad esempio NHibernate ti puoi inserire nella pipeline della
>> ISession e li fare pressoché tutto in maniera trasparente.
>
> Uhm... ma così non si crea una dipendenza Modello --> Applicazione?

� un esempio e probabilmente in molti casi la risposta alla tua domanda
sarebbe si, c'� per� anche da dire che nello specifico dell'esempio il
"plug" sarebbe completamente trasparente e configurabile dall'esterno
quindi soddisferebbe appieno il requisito. Questo � uno di quei casi da
valutare:
a) solo ed esclusivamente se si verifica e non a freddo cos� tanto per
farlo;
b) cosa per caso perch� potresti scoprire che ogni volta preferisci una
soluzione diversa ad un problema simile.

>> pensavo al motore di IoC e all'esempio dei repository che ha molto poco
>> di real-life, nulla di più. Nella vita reale la modellazione di uno
>> strato di business è decisamente più complessa.
>
> ...e torniamo alla domanda iniziale: qualche esempio?
> :-)

bella domanda, noi ci facciamo un corso di un po' di giornate,
"architettura pura" e "caliamo la fuffa nella realt�" :-) difficile da
riassumere in un poche parole... Andrea ci ha scritto un libro :-)

> Ciao e grazie,
> Giulio
> --

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> bella domanda, noi ci facciamo un corso di un po' di giornate,
> "architettura pura" e "caliamo la fuffa nella realtà" :-) difficile da
> riassumere in un poche parole... Andrea ci ha scritto un libro :-)

Il libro di Andrea è qui sulla mia scrivania.
Confesso di fare un po' di fatica a metabolizzarlo anche perché dei casi
"limite" come qelli da mi evidenziati non sono presentati. Ma forse non
ho letto bene il capitolo relativo a NHibernate. :-)

Ciao,
Giulio
--

Ciao Giulio,

You wrote on 23/10/2009 :
> Il libro di Andrea è qui sulla mia scrivania.
> Confesso di fare un po' di fatica a metabolizzarlo anche perché dei casi
> "limite" come qelli da mi evidenziati non sono presentati. Ma forse non
> ho letto bene il capitolo relativo a NHibernate. :-)

� obietivvamente difficile che un libro possa affrontare tutti i
singoli casi d'uso. Per questo esiste Guisa :-)

Quindi massacraci! ;-)

> Ciao,
> Giulio
> --

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Ciao Mauro,

mauroservienti wrote:
> � obietivvamente difficile che un libro possa affrontare tutti i
> singoli casi d'uso. Per questo esiste Guisa :-)
> Quindi massacraci! ;-)

Ok, provvederò ASAP. :-)

ciao e grazie,
Giulio
--