Entità in stato non valido

2

Sto cercando di sviluppare le mie entità in modo che non possano essere in uno stato non valido.

In particolare, sto iniziando con la mia entità cliente. Questo avrebbe campi come:

  • Titolo (enum)
  • FirstName (stringa)
  • Cognome (stringa)
  • Indirizzo (valore oggetto con altri 6 campi)
  • MainTelephone (stringa)
  • AlternateTelephone (string)
  • EmailAddress (stringa)

Ho aggiunto metodi come ChangeOfAddress () per facilitare la modifica dell'indirizzo, che garantirà l'inserimento di un indirizzo valido in sostituzione.

Nell'interfaccia utente, considero la maggior parte dei campi (ad eccezione di AlternateTelephone e EmailAddress) come "obbligatori", incoraggiando gli utenti a completare campi come Title per rendere più facile indirizzare le mailing in futuro.

Per metodi come ChangeOfAddress () il concetto di 'stato non valido' è facile, poiché posso applicare la convalida sul nuovo oggetto valore Indirizzo, ma per la costruzione di un nuovo oggetto Cliente non sono così sicuro.

Credo che la mia domanda sia, se il minimo indispensabile per la costruzione di un'entità Cliente includa tutti i campi che ritengo siano "richiesti" dal punto di vista dell'interfaccia utente? Non riesco ad immaginare come la creazione di un cliente con solo un nome e cognome (senza dettagli di contatto), sarebbe valida nel senso commerciale in cui intendo utilizzare l'oggetto cliente. Sebbene in un certo senso FirstName e LastName sono buoni punti di partenza per una descrizione minima di un cliente e immagino che il cliente non sarebbe "non valido", sarebbe semplicemente privo di informazioni sufficienti per essere utile alle mie esigenze di business (che sarebbe, per essere in grado di contattarle).

Spero che questo abbia senso, sarei interessato a sentire qualsiasi opinione, mentre sto ancora imparando mentre vado.

    
posta Adrian Thompson Phillips 20.04.2013 - 23:11
fonte

1 risposta

3

Certo, vai avanti. Scrivi il tuo costruttore in modo che richieda tutti i campi richiesti nel solito percorso "percorso felice" per creare un cliente. Se funziona, bene! Hai completato parte dei requisiti e applicato l'integrità di un asset di dati chiave contemporaneamente.

Se non funziona, avrai imparato qualcosa sul sistema che non conoscevi prima, cioè che le tue ipotesi sul flusso di dati erano sbagliate su un punto importante. Questo ti permetterà quasi certamente di creare un modello migliore del dominio: rivedi le tue ipotesi e rivedi il codice per abbinarle, e il sistema ne trarrà profitto.

Si noti che l'assunzione di una supposizione errata non è in alcun modo vergognosa o una battuta d'arresto. I modi in cui anche le assunzioni più elementari possono andare storte sono molteplici. Forse è necessario inserire una chiave deve perché è troppo preziosa per lasciarla passare anche senza aver completato il questionario. Forse hai bisogno di interoperare con un sistema legacy con regole di opzionalità differenti. Forse lo stato della California si separa, così che un contatto precedentemente valido diventa non valido anche se i dati sono gli stessi di prima! Il mio punto è: voi vorrete rivedere le ipotesi. Se li hai inseriti nei termini della tua lingua, il compilatore ti avviserà quando ciò accade. Se non lo fai, puoi continuare per un po 'seguendo una logica che non ha più senso senza notarlo . Ecco perché rendere esplicite le ipotesi è una buona cosa.

    
risposta data 21.04.2013 - 13:32
fonte

Leggi altre domande sui tag