Elucubrazioni su caso specifico di Domain Model

rated by 0 users
This post has 3 Replies | 2 Followers

Top 25 Partecipanti
Post 44
Punteggio 685
4Net Posted: 07-14-2010 19.33

Un saluto a tutti.
Su una nuova applicazione sto cercando di rivedere la struttura che uso abitualmente cercando di spingere al massimo su DDD.
Considerando che:
-posso avere entita di tipo persona e entità di tipo azienda (persona giuridica)
-posso avere entità di tipo cliente che "dovrebbero" derivare da persona fisica o persona giuridica (perchè un cliente può essere privato e azienda)
Lato db una tabella mantiene i dati della "persona" (che puo essere sia fisica che giuridica ) una tabella mantiene i dati legati solo alla entità cliente e un riferimento alla "persona".
Il dominio:
Cercando di avere un tipo per ogni entità del dominio reale (Person,Company,Customer) come trovate la seguente soluzione?

//Comune per Person e Company
abstract class PersonBase

  protected PersonType Type { get; set; }   //giuridica o fisica
  protected string Description1 { get; set; } 
  protected string Description2 { get; set; } 
  protected Address AddressInfo { get; set; }
  ...
}

public class Person : PersonBase
{
    public Person()
    {
        Type = PersonType.NaturalPerson;
    }
    public string Name { get { return Description1; } set { Description1 = value; } }
    public string Surname { get { return Description2; } set { Description2 = value; } }
    ...
}

public class Company : PersonBase
{
    public Company()
    {
        Type = PersonType.LegalPerson;
    }
    public string Name { get { return Description1; } set { Description1 = value; } }
    ...
}
Ora sto pensando a come strutturare la classe Customer. Consigli?

Mentre scrivo penso che probabilmente mi sto complicando la vita per niente.
Forse meglio una Person per gestire le due entità di dominio e una Customer che eredita da quest. Magari mi semplifico anche il mapping.

  • | Punteggio Post: 20
Top 25 Partecipanti
Maschio
Post 67
Punteggio 1.440

oki, è un classico caso di implementazione del "Party pattern". 2-"consigli"-2:

 

  • Customer non deriva nè da Persona nè da Organizzazione, ma compone una istanza di Party
  • Dai una occhiata allo (per rimanare in tema di DDD) Shared Kernel di Agorà su CodePlex: per quanto embrionale, dovrebbe essere sufficientemente intelleggibile.

Ricapitolando:

  • Classe "Party" astratta
  • Person e Organization ereditano Party
  • Customer ha una proprietà di tipo Party

Top 25 Partecipanti
Post 44
Punteggio 685

Ok,
Ho visto qualche cosa su NSK ora passo ad Agorà.
Ecco anche il perché del nome "Party" che mi sembra di capire sia preferibile a Person come nomenclatura ( che in effetti potrebbe essere un po' fuorviante) .

>Customer non deriva nè da Persona nè da Organizzazione, ma compone una istanza di Party
In effetti avevo usato anche una terminologia errata nella domanda.

P.s.:
Ehm..."party pattern" mai sentito o forse cancellato dalla memoria.  :-(
Cmq vedo che è una variante del Composite applicata proprio a questo tipo di realtà (people, organizations, locations, contacts, and addresses ) .
http://c2.com/cgi-bin/wiki?ContactAndAddressModels

Ciao, grazie.

  • | Punteggio Post: 5
Top 25 Partecipanti
Post 44
Punteggio 685

Ho appena dato uno sguardo a Agorà, molto interessante!

Il caso in oggetto sarebbe appunto equivalente a Party,Person,Organization e User.
La differenza è che in Agorà ogni entità ha una tabella "dedicata" io pensavo di far vivere Party,Person e Organization su una unica tabella distinguendo con un "flag" Person da Organization.
A tal proposito però ho una curiostità sulla soluzione adottata su Agorà.
Come ci si dovrà comportare quando, per esempio, dovremo recuperare dalla base dati  uno specifico User e da questo la relativa Person (Party).
Come dovremmo comportarci  e come si comportera EF4?

Grazie,Ciao.

  • | Punteggio Post: 5
Pagina 1 di 1 (4 elementi) | RSS
Powered by Community Server (Commercial Edition), by Telligent Systems