L'opportunità di salvare files sul database è stato ed è ancora argomento di
discussione.
Personalmente non penso che in assoluto sia giusto o sbagliato decidere di
mantenere i contenuti di files all'interno del
database piuttosto che sul file system, ritengo che siano le esigenze
applicative che ci portano ad effettuare una scelta piuttosto che un'altra.
Detto questo vorrei illustrare un metodo per la gestione dei file utilizzabile
nel caso si decida di mantenere i files sul database.
Quanto descritto di seguito nasce dalla seguente situazione:
- applicazione con DAL basata su NH
- esigenza di gestire un elenco di allegati per alcune entity dell'object model
- esigenza di mantenere buone prestazioni applicative
- necessità di mantenere i contenuti dei files sul DB (per esigenze di backup e disaster recovery manifestate dal cliente)
A livello di sviluppo ho deciso inoltre di inserire le seguenti condizioni:
- gestire tutti gli allegati, indipendentemente dall'entity a cui sono collegati, con una singola entità
- sfruttare il cascading per persistere gli allegati insieme alle entità a cui sono collegati
Allegato al post trovate un progetto in cui è riportata la soluzione adottata suddivisa in due versioni. La prima versione risolve il problema ma soffre di un problema di efficenza legato al mancato lazy loading dei contenuti del file, mentre nella seconda questo problema si risolve.
La situzione descritta prevede un'entità di tipo MessageInfo contenente un insieme di allegati rappresentati dall'entità AttachmentInfo.
Soluzione iniziale
La prima soluzione introduce le due entità indicate in precedenza:
- MessageInfoV1: classe per la gestione dei messaggi contenente al suo interno un elenco di allegati
- AttachmentInfoV1: classe per la gestione del singolo allegato in cui per semplicità memorizzo solo il nome del file ed il contenuto ma che nella realtà potrebbe contenere informazioni aggiuntive (ad es. data di caricamento, data del file ecc.)
Per quanto riguarda il mapping di NH è stato effettuato su 3 tabelle, gestendo il lazy loading della collezione di attachment per i messaggi:
<class name="MessageInfoV1" table="message_v1" polymorphism="explicit">
<id name="MessageId" >
<generator class="assigned"/>
</id>
<property name="Sender" length="32" />
<property name="Recipient" length="32" />
<property name="MessageText" length="1024"/>
<bag name="Attachments" table="message_attachments_v1" lazy="true" cascade="all-delete-orphan">
<key column="MessageId"/>
<many-to-many column="AttachmentId" class="AttachmentInfoV1"/>
</bag>
</class>
<class name="AttachmentInfoV1" table="attachment_v1" polymorphism="explicit">
<id name="AttachmentId" >
<generator class="assigned"/>
</id>
<property name="FileName" length="256" />
<property name="Content" type="binary"/>
</class>
Questa soluzione è però soggetta ad un problema, se si vuole recuperare un messaggio ed elencare i nomi dei files allegati a meno di non definire una query od un criteria ad hoc si ottiene il caricamento di tutto l'attachment compreso il contenuto.
Per esempio il seguente codice.
message = s.Get<Model.Solution1.MessageInfoV1>(messageId);
message.MessageText = "Messaggio di test modificato";
foreach (var attachment in message.Attachments)
Console.WriteLine("Attachment filename \"{0}\" (Id: {1})", attachment.FileName, attachment.AttachmentId);
risulta in un caricamento di tutti i contenuti dei files anche se non necessari.
DEBUG NHibernate.SQL - SELECT messageinf0_.MessageId as MessageId5_0_, messageinf0_.Sender as Sender5_0_, messageinf0_.Recipient as Recipient5_0_, messageinf0_.MessageText as MessageT4_5_0_ FROM message_v1 messageinf0_ WHERE messageinf0_.MessageId=?p0;
DEBUG NHibernate.SQL - SELECT attachment0_.MessageId as MessageId1_, attachment0_.AttachmentId as Attachme2_1_, attachment1_.AttachmentId as Attachme1_4_0_, attachment1_.FileName as FileName4_0_, attachment1_.Content as Content4_0_ FROM message_attachments_v1 attachment0_ left outer join attachment_v1 attachment1_ on attachment0_.AttachmentId=attachment1_.AttachmentId WHERE attachment0_.MessageId=?p0;
Ovviamente il medesimo problema si manifesta anche in fase di update degli attachment.
Introdurre il lazy loading per il contenuto del file
Per evitare il problema descritto occorre introdurre il lazy loading del contenuto del file.
Per fare questo è necessario gestire una entità apposita da associare uno ad uno con l'entità dell'attachment.
Il nuovo object model è il seguente:
Per rendere praticamente identica l'interfaccia dell'entità AttachmentInfo la proprietà AttachmentContent è segnata come protect, mentre mantengo la proprietà Content che fa riferimento a AttachmentContent.Content, in questo modo la gestione dei contenuti tramite una entità ad-hoc viene nascosta agli utilizzatori della libreria.
protected virtual AttachmentContentInfoV2 AttachmentContent { get; set; }
public virtual byte[] Content
{
get { return AttachmentContent.Content; }
}Per quanto riguarda il mapping viene utilizzato un mapping one-to-one per la proprietà AttachmentContent ovviamente con il lazy loading abilitato.
<class name="AttachmentInfoV2" table="attachment_v2" polymorphism="explicit">
<id name="AttachmentId" >
<generator class="assigned"/>
</id>
<property name="FileName" length="256" />
<one-to-one name="AttachmentContent" class="AttachmentContentInfoV2"
lazy="proxy" cascade="all-delete-orphan" />
</class>
<class name="AttachmentContentInfoV2" table="attachment_content_v2" >
<id name="AttachmentId" >
<generator class="assigned"/>
</id>
<property name="Content" type="binary"/>
</class>
Con questa nuova soluzione l'interrogazione dell'elenco dei file allegati risulta nella seguente query:
DEBUG NHibernate.SQL - SELECT messageinf0_.MessageId as MessageId2_0_, messageinf0_.Sender as Sender2_0_,
messageinf0_.Recipient as Recipient2_0_, messageinf0_.MessageText as MessageT4_2_0_
FROM message_v2 messageinf0_ WHERE messageinf0_.MessageId=?p0;
DEBUG NHibernate.SQL - SELECT attachment0_.MessageId as MessageId1_, attachment0_.AttachmentId as Attachme2_1_,
attachment1_.AttachmentId as Attachme1_0_0_, attachment1_.FileName as FileName0_0_
FROM message_attachments_v2 attachment0_
left outer join attachment_v2 attachment1_
on attachment0_.AttachmentId=attachment1_.AttachmentId
WHERE attachment0_.MessageId=?p0;
Inoltre se si prova ad eseguire un'azione di update che non coinvolge il nome file anche in questo caso il contenuto non viene coinvolto.
s = NHFactory.GetNewSession();
using (ITransaction tx = s.BeginTransaction())
{
message = s.Get<Model.Solution2.MessageInfoV2>(messageId);
message.MessageText = "Messaggio di test modificato";
foreach (var attachment in message.Attachments)
{
attachment.FileName = attachment.FileName.Replace("XML", "xm_");
_log.InfoFormat("Attachment filename \"{0}\" (Id: {1})", attachment.FileName, attachment.AttachmentId);
}
s.Flush();
s.Close();
}
UPDATE message_v2 SET Sender = ?p0, Recipient = ?p1, MessageText = ?p2 WHERE MessageId = ?p3;
UPDATE attachment_v2 SET FileName = ?p0 WHERE AttachmentId = ?p1;
UPDATE attachment_v2 SET FileName = ?p0 WHERE AttachmentId = ?p1;
UPDATE attachment_v2 SET FileName = ?p0 WHERE AttachmentId = ?p1;
Codice di esempio
Il codice di esempio è disponibile qui.
Nel file compresso è disponibile il database MySQL e la libreria base.
