Come inizializzare una classe?

Question

Il problema è molto semplice, ho un "archivio" di classe, voglio caricare la sua "StockName" proprietà ", codice interno' dal db.

così che Patten dovrei usare?

modello 1) Utilizzare classe di servizio per crearlo

public interface IStockService{ 
      Stock GetStock(string stockCode); 
      void SaveStock(Stock stock); 
     } 
     public class StockService : IStockService{ 
     } 

     IStockService stockService = new StockService(); 
     Stock stock = stockService.GetStock(); 

modello 2) Utilizzare metodo statico in magazzino

     public class Stock{ 
      public static Stock GetStock(){ 
       Stock stock = new Stock; 
       //load stock from db and do mapping. 
       return stock; 
      } 
      public void Save(){ 
      } 
     } 

modello 3) Utilizzare costruttore per caricare

 public class Stock{ 
      public Stock(){ 
       //load stock from db and do mapping. 
       this.stockName = ... 
       this.stockCode = ... 
      } 
     } 

testo 1: sembra che usare tanti codice per creare un oggetto stock, e il metodo "SaveStock" sembra un po 'non oggetto-oriente.
per il modello 2: il metodo "Salva" sembra ok, ma il metodo GetStock è un metodo statico, sembra una classe di utilità che utilizza sempre il metodo statico.
per il modello 3: il costruttore caricherà i dati da db quando si inizializza. sembra anche confuso.

Answer 1

qualcosa di simile al metodo 1, dove si dovrebbe mettere in classi di livello DB per ottenere l'oggetto caricato da lì, anche se si consiglia di utilizzare un ORM per prendersi cura di tutti i accesso ai dati per voi

Answer 2

Personalmente mi piace che i miei oggetti siano astratti dalla loro origine dati, quindi andrei con un metodo come # 1. # 3 che non vuoi assolutamente fare ... troppa elaborazione in costruttori può metterti nei guai. È probabile che la preferenza di # 1 vs # 2 si riduca a quanto "caricato" vuoi che i tuoi oggetti di dati siano.

Se si prevede di ottenere il proprio oggetto da un'altra fonte di dati, si vorrà attenersi al n. 1 poiché offre una maggiore flessibilità.

Answer 3

Vorrei andare con il modello 1. Presenta una chiara separazione delle preoccupazioni tra il modello di dominio e l'accesso ai dati. È anche più facile da testare l'unità.

Answer 4

se si desidera inizializzarlo automaticamente, quindi utilizzare il costruttore statico che è stato chiamato dal servizio class. Loader .net.

Answer 5

modello 2) è il patten di fabbrica (metodo) e mi ricorda i singleton (static = singleton). Nota singletons are evil. Il metodo factory non è polimorfo. Non puoi cambiarlo per i test (cioè non puoi prenderlo in giro). È malvagio! Evitalo!

modello 3) viola che il costruttore non dovrebbe fare troppo. A mio parere, interrogare il database è troppo per un ctor. L'oggetto e la sua creazione sono preoccupazioni diverse e dovrebbero essere separati. Un'ulteriore ulteriore creazione di un'istanza dovrebbe essere separata dall'istanza, quindi prova ad usare le fabbriche (o gli iniettori). Puoi sostituire la fabbrica più facilmente della "nuova classe" diffusa attraverso il tuo codice.

modello 1) rimane, che è un modello di fabbrica astratto. È buono. È possibile utilizzare un'altra implementazione per il test (una simulazione). Separa la creazione dall'oggetto. (Principio di responsabilità singolo come Carl Bergquist lo chiama.)

quindi vorrei andare con il modello 1.

Answer 6

si dovrebbe separare la classe di entità (magazzino) e la logica che lo popola (stockservice), ma invece di scrivere una classe di stockservice usa semplicemente un orm per mappare db alla tua classe di entità (stock).

Answer 7

Ti manca un pezzo importante. In particolare, dove si ottiene la stringa di connessione per parlare con il database?

Aggiorna ognuno dei tuoi esempi con il punto da cui proviene la stringa di connessione e penso che farà scattare la risposta giusta.

Answer 8

Motivo 1:
- Più facile per testare
- Principio di responsabilità singolo
- può richiedere più codice.

Modello 2:
- Classi/metodi statici possono rendere molto più difficile il derisione. Cerco di evitarlo il più possibile.

Modello 3:
- Va bene per le classi piccole. Ma mantieni la logica lontana dal costruttore

Ma penso che Orm e serializzazione coprano la maggior parte delle parti (creazione di oggetti).