Generazione numero documento

[Mauro Servienti]

Ciao,

ho iniziato questo thread sul gruppo en qui:
http://groups.google.com/group/nhusers/browse_frm/thread/a34404f450ec2278 e
Fabio mi ha consigliato di spostare la discussione sul gruppo italiano.

Lo scenario lo possiamo riassumere con un esempio che credo sia decisamente
noto J: Generazione del numero di fattura.

Quello che vorrei fare è evitare di generare il numero fattura a "mano",
adesso infatti prima di persistere l'entità transient "cerchiamo" il nuovo
numero e all'interno della stessa transazione lo assegniamo alla entità e
infine committiamo. Ci sono svariate cose che non mi piacciono di questo
approccio.

Vorrei invece iniettare questa logica nel processo di "insert" di NH, nel
nostro dominio abbiamo però svariate entità che seguono questa logica e ogni
entità ha la sua logica peculiare per generare il "numero documento".

Grazie, ciao

.m

[Fabio Maulo]

Ciao Mauro.

Da quello che ho capito tu non mostri mai il numero del documento durante il processo di emissione, corretto ?

2009/8/29 Mauro Servienti <mauro.s...@gmail.com>

--
Fabio Maulo

[Mauro Servienti]

Ciao Fabio,

esatto, il numero fattura viene assegnato solo all'atto della insert, in
realtà sulla entity c'è una proprietà DocumentNumber, in solo get,
valorizzata al valore di default. Il "numero documento" non è esposto come
int, ad esempio, ma è un custom type in questo modo è sempre valorizzato
anche quando la entity è transiente.

La questione della fattura è un esempio, abbiamo scenari più complessi in
cui il documento può essere generato e salvato senza l'assegnazione di un
numero perchè ancora in stato "draft" e solo al passaggio in definitivo
avere assegnato un numero documento.

Grazie, ciao
.m

[Fabio Maulo]

Si si... giá só como funzionano ste cose... anche vivo in Argentina ho programmato gestionali in Italia per circa 14 anni.

Allora... la cosa non tanto difficile

Se non sbaglio dovresti avere qualcosa tipo "DefinizioneNumeratore" dove si definisce il comportamento (quando/se ricominciare da uno, il nome del numeratore ecc.).

Poi dovresti avere una entitá a parte che sia responsabile di mantenere, per ogni definizione, un "codiceDiRiinizio" e il numero disponibile.

Per le fatture dovrebbe essere qualcosa tipo:

[10](idDefinizioneNumeratore)

[2008](codiceDiRiinizio che per le fatture dipende solo dall'anno; per esempio)

[18579](prossimo numero fattura per il codiceDiRiinizio[2008])

[30/12/2008 15:01:01](momento ultima richiesta numero)

Ci siamo ?

--
Fabio Maulo

[Mauro Servienti]

Ciao,

si direi che ci siamo.
Beato te :-) io continuo a farlo... che barba che noia.

[Fabio Maulo]

Nei passi successivi entreremmo in una serie di storie che hanno a che fare con l'organizzazione dell'applicazione...

In ogni caso nessuna di queste cose hanno a che fare strettamente con la persistenza.

In qualche posto drovresti avere qualcosa di simile a:

IProgressivo GetProgressivo(definizioneProgressivo)

IProgressivo.Attualizza() o un Attualizza(IProgressivo)

Questo é uno di quei casi dove il lock pessimista é utile a risolvere il problema anche se usando il timestamp del progressivo (cosí come mostrato sopra) si puó risolvere il tutto anche senza lock pessimista.

Nel Get con NH si dovrebbe eseguire session.Get<IProgressivo>(LockMode.Upgrade) e poi nel Attualizza(IProgressivo) farai il +1 e attualizerai il timestamp; il tutto funziona usando la stessa transazione usata per registrare il documento fiscale.

Sta storia la puoi mettere dentro i vari IPreXYZ listeners peró stai occultando una parte del business dentro il persistent-layer e non credo sia una buona idea.

--
Fabio Maulo

[Mauro Servienti]

Quindi tu mi stai dicendo:

- definisci una entità di dominio che incapsula la logica di genrazione del
numero documento;
- all'interno della transazione, prima dell'insert, fai generare alla entità
un nuovo numero e assegnalo;
- fai il commit;

Questo genera:
- il commit del documento con il suo numero documento;
- il commit dell'entità che gestisce la generazione del numero con le nuove
informazioni (ultimo numero creato, quando, da chi etc...);

dato che entrambe le entity gesticono la concorrenza ottimistica tramite
timestamp se qualcuno fa lo stesso processo nel frattempo invalida
inevitabilmente il mio numero documento e non ho bisogno di gestire lock
pessimistici. In caso di concurrency-exception quindi butto la sessione ne
apro un'altra e ci riprovo.

Ci sono?
.m
______________________________________________________________
Mauro Servienti | mauro.s...@gmail.com | Microsoft MVP - Visual C# /
MCP

[Fabio Maulo]

Diciamo che ci sei.... ti ho proposto il lock pessimista perché con MsSQL2005 la precisione del timestamp non é buonissima.

Con MsSQL2008 usando Timestamp2 giá é meglio.

In ogni caso il lock pessimista previene ste storie con ogni RDBMS anche se ha qualche sideeffect in piú.

Nel caso di exception ci sono vari modi anche li di risolverlo peró va bene.

2009/8/29 Mauro Servienti <mauro.s...@gmail.com>

--
Fabio Maulo

[Mauro Servienti]

Perfetto, grazie mille.
Provo e se ho problemi torno :-)

[Fabio Maulo]

2009/8/30 Mauro Servienti <mauro.s...@gmail.com>

Perfetto, grazie mille.
Provo e se ho problemi torno :-)

beh... sarebbe meglio che torni ogni tanto a vedere se qualche altro ha problemi e tu hai la soluzione.

--
Fabio Maulo

[Mauro Servienti]

Ciao,

questo è poco ma sicuro, mi sono sottoscritto sia il gruppo “it” che quello “en” per avere la notifica via email dei post giornalieri. Uso NH da poco più di 2 settimane e ormai sono praticamente “addicted” ☺

.m

---------------

From: nh...@googlegroups.com [mailto:nh...@googlegroups.com] On Behalf Of Fabio Maulo
Sent: domenica 30 agosto 2009 16:03
To: nh...@googlegroups.com
Subject: [NHibernate-It] Re: Generazione numero documento