Buoni principi per spiegare l'uso degli oggetti dati

1

Ho un piccolo bisogno di chiarimenti sui nomi. Prima una breve descrizione della mia posizione. Mi preparo come esordiente dando una descrizione del lavoro per sviluppatori junior, che ha anche fornito un'altra prospettiva su quanto sia importante la comunicazione e per metterla fuori dubbio.

È sufficiente; Mi piace capire cosa intenda con "Contesto" e mi piace dare una descrizione adottata di cosa sia un POCO. Ora, queste non sono le parole esattamente problematiche. Non abbiamo ancora parlato. Lo descrivo più come problema semantico e mi concentro sui dati e sull'IoC, perché c'è il punto che incontreremo (He = GUI, I'm BL).

Fornisco un esempio tipizzato manualmente come riferimento per nominare parti diverse di esso. Alcuni termini sono locali per un produttore o uno strumento e alcuni sono usati più generici, che preferisco quest'ultimo.

// Poco, Model?
public class Customer
{
    public int CustomerId { get; set; }
    public string Name { get; set; }
}


// A short sign of repository pattern
public class CustomerContext
{

   // Is this a context or even a entity? 
   List<Customer> cust;
   public CustomerContext()
   {
      cust = new List<Customer>();
      cust.Add(new Customer() { CustomerId = 1, Name = "Doe" });
      cust.Add(new Customer() { CustomerId = 2, Name = "John" });
      cust.Add(new Customer() { CustomerId = 3, Name = "Zelda" });
      cust.Add(new Customer() { CustomerId = 4, Name = "Kim" });
   }

   public IQueryable<Customer> Get()
   {
      return cust;
   }
}

* Quali termini si adattano meglio? *

"Cliente" è un modello (preso da MVC)? In poche parole, intendiamo lo stesso con POCO?

Come faccio a chiamare i dati digitati di esempio sopra? Mocks? Semplicemente "Dati"?

Come faccio a chiamare l'oggetto CustomerContext? Un repository? Un contesto? È un'entità?

Ci sono altri termini che sono sfuggiti a questo ambito?

Sembra comune scrivere su repository e generici, anche se rientrano nell'ambito di un produttore (laddove "entità" indica comunemente Entity Framework). Una strong indicazione di cosa significhi cosa (e quando), sarebbe di aiuto.

    
posta Independent 25.07.2012 - 10:06
fonte

2 risposte

3

Are 'Customer' a Model? Which it appear to be called in MVC?

Sì, può essere chiamato un modello. Spesso in MVC, il modello non è semplicemente una singola entità aziendale: potrebbe essere, ad esempio, una raccolta di più entità e varie impostazioni utente racchiuse in una sola, tutto ciò che la vista deve essere in grado di svolgere il proprio lavoro.

Does we, simply put, mean the same with POCO?

Sì, è un POCO, perché non stai implementando alcuna interfaccia specifica o erediti da qualche framework di entità.

What do I call the static typed data (in such case)? Mocks? Simply "Data"?

Probabilmente lo chiamerei dati di test. È abbastanza difficile definirlo un "finto" poiché a questo punto sembra essere la tua implementazione principale. Non ho mai incontrato la parola falso usata al di fuori del contesto del test unitario, quello che hai qui sembra essere più in linea con il termine "falso" (vedi articolo di Wikipedia su questi termini particolari).

What do I call the object CustomerContext? A repository? A Context? Is it an Entity? I often confuse these terms with what I mean.

Sembra che sia l'inizio di un schema del repository .

Per inciso, List<Customer> cust; è una convenzione di denominazione piuttosto scadente: prova a non usare le abbreviazioni. Sarà confuso quando la Banca Depositaria, la Custard e altre classi simili inizieranno a fare le apparizioni nel tuo codice:)

    
risposta data 25.07.2012 - 14:38
fonte
1

Are 'Customer' a Model? Which it appear to be called in MVC?

A mio parere: Customer , è un DTO (Data Transfer Object). Come è ora, non c'è logica o comportamento in Customer - questo è generalmente ciò che lo separa dall'essere un'entità aziendale, un'entità dominio o qualcosa del genere. Per questo motivo, non lo chiamerei necessariamente un modello esattamente, o direi che il tuo modello è anemico ( o hai semplicemente semplificato l'esempio e questo non si applica).

Does we, simply put, mean the same with POCO?

Questo potresti davvero averlo prima alzato. In ogni caso, POCO viene spesso utilizzato nel contesto di un ORM. Significa semplicemente che non sei obbligato ad ereditare un tipo di entità di base richiesto dal tuo framework di persistenza.

What do I call the static typed data (in such case)? Mocks? Simply "Data"?

Come afferma Daniel B, si tratta di dati di test. Un finto è un oggetto in cui si forniscono le aspettative che l'oggetto dovrebbe restituire (in fase di esecuzione / tempo di test). Un falso è più o meno la stessa cosa, tranne che le aspettative sono spesso fornite in fase di progettazione. C'è una buona scrittura qui .

What do I call the object CustomerContext? A repository? A Context? Is it an Entity? I often confuse these terms with what I mean.

Sulla base di tutte le tue domande, propongo alcune letture / ricerche:

E, ultimo e più importante di tutti: il maggiore vantaggio dei modelli di progettazione è che forniscono la capacità di comunicare sul codice a un livello più efficiente e più astratto. I altamente suggeriscono alcuni buoni libri di modelli in quanto questo è esattamente il problema che stai riscontrando. Ci sono molte domande sulla rete SE che hanno risposte meravigliose. Ad esempio .

    
risposta data 25.07.2012 - 15:19
fonte

Leggi altre domande sui tag