This project has moved and is read-only. For the latest updates, please go here.

Entities ... intoccabili?

Topics: Developer Forum
Sep 29, 2006 at 5:20 PM
Così come sono ora, le entities non sono serializzabili, tantomeno supportano la notifica del cambiamento delle proprietà (INotifyPropertyChanged).
Andrea mi diceva che uno dei motivi è la presenza del campo Bitmap nella classe Employee (Bitmap non è serializzabile).

Ora ci sono diversi ragionamenti che non mi fanno comprendere le motivazioni di questa rigidità:
1. Bitmap è una classe di System.Drawing. Quindi Employee sposando il mondo GDI+ è fortemente legata al modello winform e asp.net. Bitmap non è fruibile direttamente in WPF e questo "sporca" la purezza di Employee.

2. La risorsa bitmap può essere conservata come un byte array internamente e poi esposta in qualsiasi altro modo (oggi bitmap, domani image, o qualsiasi altra cosa).

3. Rendere serializzabili le entities e farle implementare interfacce come la INotifyPropertyChanged riduce sensibilmente il codice da scrivere. La scelta rigida è difficilmente sostenibile di fronte a chi non vede un vantaggio tangibile a non farlo.

4. Perché serializzabili (1)? Sarebbe mia intenzione creare uno strato che permetta di mettere il biz layer su un application server (pc con IIS) ed erogare le entities via remoting. Remoting (così come qualsiasi altra forma di comunicazione) necessità di serializzare in qualche modo i dati.

5. Perché serializzabili (2)? Ok, si può derivare le entities e aggiungere la serializzazione sulla classe derivata. Ma non riesco a giustificare questo step. Dovendo poi aggiungere INotifyPropertyChanged, significa fare l'overload di tutte le proprietà ... un lavoraccio.

Il timore non è tanto quello di scrivere del codice per questo "sample project" ma mi sembra difficile proporlo come modello.
Se una scelta di puro design fa a botte con il tempo di sviluppo, allora è difficilmente sostenibile. Sappiamo bene che i costi sono la prima voce in un progetto di sviluppo.

Ok, cominciate a flammarmi :-)
Sep 30, 2006 at 3:04 PM
Sul discorso della bitmap su Employee nn vedo blocchi particolari...
Idem per l'implementazione di INotifyPropertyChanged, (normalmente non lo faccio nei miei progetti perchè uso utility come ObjectViews che si occupano della visualizzazione), ma in questo caso non ce lo possiamo permettere.

Se l'applicazione è in layering....è anche sensato pensare che possa comunicare fuori processo in una topologia multi-server. Via remoting o altro...
Sul fatto di rendere serializzabili le entity avremo però un problema a prescindere dalla bitmap. Per adesso le entity che espongono collezioni, lo fanno tramite interfacce IList<T>,
in modo che i vari DAL concreti iniettino le loro collezioni specializzate. Anche mettendo delle classi astratte che implementino l'interfaccia (in modo che risulti serializzabile)
dovremmo comunque specificare l'attributo XmlInclude(typeof(TipoConcreto)), che stando proprio sui DAL produrrebbe una reference circolare.
Quindi data la giusta necessità di serializzazione....dovremmo affrontare anche questo problema...(a manina?...oddio)

Per il discorso di NSK come modello di riferimento...tasto dolente...dobbiamo trovare il giusto punto di equilibrio tra quelle
che sono le esigenze di design (manutenibilità, estendibilità e testabilità) e anche esigenze più strettamente tecnologiche.
Se in qualche particolare caso, una scelta architetturale dovesse penalizzare fortemente una scelta tecnologica (o viceversa)
magari è il caso di fare una branch del progetto piuttosto che astrarre (ingarbugliare) troppo NSK?

(il discorso è generico e non basato sul problema della serializzazione)
Oct 1, 2006 at 10:53 PM
Ci ho messo un po' a rispondere perché ho voluto fare un test veloce con remoting.
Il problema che hai sollevato sulle interfacce non dovrebbe essere di intralcio. Cioè dichiarando la collection come IList, posso serializzare la collection senza problemi di sorta.

Qui mi sembra però che ci sia da prendere una decisione su praticità e filosofia del kit.
- se questo kit deve fungere da modello per applicazioni reali, è necessario dimostrare che il codice che si scrive è utile e non è solo allo scopo di applicare quello che è scritto su un libro.
- se questo kit è un lab per i pattern, allora il discorso è totalmente differente e sta benissimo così com'è.

Mi pare evidente che le due cose non siano conciliabili.
Se la decisione sarà di volgere al pratico, allora dobbiamo ragionare su tutto quello che può essere utile aggiungere/modificare/togliere senza ovviamente impoverire l'architettura, la separazione dei layer, etc.