Dividere le definizioni oggetto (catalogo) dalle istanze (oggetti fisici)

Question

Dividere le definizioni oggetto (catalogo) dalle istanze (oggetti fisici)

#1 da (1 voti)

2

Mi chiedo se esiste un modello di progettazione per tale problema:

Diciamo che stiamo costruendo un negozio web per un produttore di porte e finestre, dove il cliente ha un catalogo (elenco) di prodotti, dal quale può sceglierne alcuni e personalizzarli, prima di effettuare un ordine.

Ogni prodotto ha le sue proprietà definite, come nome, prezzo, descrizione. Ovviamente, il cliente non è autorizzato a modificare nessuna di queste proprietà. Ma c'è uno spazio per personalizzare il prodotto. Quando sceglie una finestra, può scegliere il colore, le dimensioni, forse un colore del vetro e scegliere alcune caratteristiche aggiuntive. Quando sceglie le porte, allora può scegliere un colore, una dimensione, ma anche un tipo di serratura.

La prima idea che mi è venuta in mente è:

Creare classi di definizioni dei prodotti (WindowDefintion, DoorsDefinition), che contengono informazioni sul nome, il prezzo, la descrizione. Questi sono elencati in un catalogo
Crea classi di istanze di prodotto (Finestra, Porte), che contengono riferimenti al prodotto, ma aggiungono anche campi personalizzabili, specifici per determinate istanze.

Gli svantaggi sono forse sciocchi, perché si tratta principalmente di creare una classe di definizione per ogni classe di istanza, ma ciò comporta anche una quantità più raddoppiata di tabelle di database e repositiories. Mi stavo chiedendo se c'è qualche altra soluzione?

Questo esempio non è il caso. Lo sto usando per facilitare la comprensione del problema. Nel caso, i prodotti non hanno una buona generalizzazione comune, che un prodotto darebbe in questo caso (utile per avere nome, descrizione e proprietà del prezzo).

design design-patterns

posta krzychu 27.11.2013 - 13:41

fonte

1 risposta

Leggi altre domande sui tag design design-patterns

Come impacchettare il contenuto statico al di fuori dell'applicazione web? Sub-instradamento in un sito SPA

score 1 · Answer 1

Le tue astrazioni appaiono troppo sottili e stai pensando di modellare il tuo livello di persistenza allo stesso modo del tuo dominio.

C'è un compromesso da fare qui.

Da un lato, se modellate i vostri prodotti in questo modo in un database, vi ritroverete con un numero maggiore di tabelle, ogni modifica a un prodotto richiederà modifiche a schema, repository, dominio e consumatore / applicazione. Questo è un progetto IMO piuttosto fragile.

Se rendi il tuo schema meno consapevole delle implementazioni di prodotto, preferendo invece archiviare valori personalizzati in un modo più chiave / valore per ogni personalizzazione del prodotto, ogni modifica a un prodotto probabilmente non richiederà modifiche dello schema e dell'archivio, solo dominio e applicazione i cambiamenti. Complicherà cose come la ricerca / il recupero e la reidratazione degli oggetti del dominio, ma questo è tipicamente ciò per cui è un livello di servizio e un modello di dominio, astraendo le specificità della persistenza.

Dipende dai requisiti dell'applicazione che non sono chiari, ma mi piacerebbe sempre puntare all'opzione numero due.

Vorrei concentrarmi sulla modellazione di un tipo di prodotto astratto contenente gli elementi comuni (id, nomi, descrizioni, prezzi) e utilizzare qualcosa come un modello di decorazione o costruttore per aggiungere le cose specifiche del prodotto in una raccolta a cui si accede utilizzando le proprietà di sottotipo create dai modelli.

I livelli di persistenza / deposito richiederebbero solo la conoscenza per salvare / caricare la raccolta nei tipi corretti che potrebbero essere fatti usando una Fabbrica.

Man mano che i requisiti cambiano e la complessità aumenta per le opzioni e le personalizzazioni del prodotto, diventa molto più semplice gestire questo tipo di modello in cui la logica si trova nel livello dominio e non si riflette nel livello di persistenza.