di Ugo Lattanzi

Orami in tutte le mie applicazioni realizzo un Domian Model sia che queste siano complesse che non.

Ora Fowler ci dice:

An object model of the domain that incorporates both behavior and data.

ed è tutto giustissimo il Domain sarà un contenitore di dati disconnesso e, nel caso avere delle implementazioni interne, ma non dovrebbe scostarsi di più da ciò.

Un'ulteriore caratteristica che dobbiamo rispettare è che il Domain deve essere quello a prescindere dal tipo di applicazione che si andrà a realizzare (Web Application, WinForm, Mobile, ecc) e dal tipo di strato dati, che sia NHibernate o un provider custom, xml o quel che volete.

Detto questo mi chiedo:
ma è giusto implementare nel domain l'interfaccia INotifyPropertyChanged dato che un'applicazione ASP.NET non sa che farsene, inoltre è giusto implementare Collection<T> per le nostre collezioni quando per un DataBinding su WinForm sarebbe più giusto utilizzare BindingList<T>???

Ora dato che ogni tipo di applicazione richiede delle caratteristiche diverse per il proprio Domain forse è il caso che queste tipo di implementazioni vengano fatte nella UI dell'applicazione e non nel Domain rischiando di avere implementazioni "pesanti" che non verrano mai utilizzate perchè il tipo di applicazione su cui gira il Domain non le richiede.

Per esempio se andiamo ad analizzare BindingList<T> e Collection<T> entrambe implementano l'interfaccia IList<T>.

Quello che mi chiedo io non è il caso che nel Domain per gestire le collection si utilizzi una sintassi del tipo:

 IList roles = new List<T> 

e l'interfaccia INotifyPropertyChanged venga implementata nel UI che la richieda e non nel Domain in modo da avere un domain "perfetto" per ogni tipo di applicazione??

Una parte di questo mio dubbio è risolvibile utilizzando un oggetto per WinForm che come dice il sito stesso:

A library to facilitate DataBinding in .NET Windows.Forms.

dimenticavo il Link.