Come costruire un framework di modellazione del prodotto

Sì, ma non dici cosa stai facendo con i prodotti.

Se hai solo bisogno di registrare le informazioni, allora hai solo bisogno di un singolo prodotto con un dizionario di attributi.

Quindi una singola vista può scorrere la collezione e produrre moduli per qualsiasi "tipo" di prodotto

Se tuttavia si dispone di una logica personalizzata per implementare per tipo, qualsiasi sistema generico diventerà presto troppo complesso. Finisci per inventare un nuovo linguaggio di programmazione per la tua configurazione che è un incubo da mantenere.

Piuttosto che seguire questa strada, vorrei risucchiare il dolore a breve termine di una vista per modello.

modifica -----

esempio di codice per il modello di dizionario semplice

using System.Collections.Generic;
    public class Product
    {
        public Dictionary<string, string> Attributes { get;set }
    }
    public class ProductFactory
    {
        public Product Create(string productType)
        {
            Product p  = new Product();
            if(productType == "chair")
            {
                p.Attributes.Add("legCount","4");
                p.Attributes.Add("material","pine wood");
            }
            return p;
        }
    }

snippet di visualizzazione del rasoio

@foreach(KeyValuePair kvp in Model.Attributes)
{
    <label>@kvp.Value<label> <input type="text" name="@kvp.Key" value="@kvp.Value"/>
}

Viste sulla risposta EAV:

A mio avviso questo è il prossimo livello. Sostituisci le stringhe con oggetti e aggiungi metadati per indicare al modulo come eseguire il rendering per tipi specifici. Tuttavia, (in breve), a mio avviso, questo spinge solo il requisito per i moduli personalizzati fino al livello degli attributi e si sta meglio andando solo per moduli personalizzati per prodotto

Problemi con questo semplice approccio al dizionario:

Non hai più prodotti strongmente tipizzati. Ad un certo punto è necessario convertire la stringa "4" gambe in un numero effettivo di gambe. se l'utente ha digitato "quattro", verrà visualizzato un errore di runtime.

Per chiarire:

Se vuoi la mia raccomandazione, è "non creare moduli autogenerati"

Quello che stai cercando si chiama "Valore attributo dell'entità" modello. Ti permetterà di avere un metamodel nel tuo database, che descrive l'elenco degli attributi di ciascuna entità (nel tuo caso i tipi di prodotto). Il metamodello può essere modificato in fase di runtime, quindi è possibile aggiungere nuovi tipi di prodotto senza modificare l'applicazione. E puoi fornire informazioni aggiuntive come "tipo di dati", "intervallo di valori consentito", "è l'attributo obbligatorio o facoltativo", "larghezza minima" e così via che è necessario per generare un modulo utile per questi dati.

Per implementare questo, dovrai aggiungere alcune funzionalità alla tua applicazione per gestire l'elenco dei tipi di prodotto disponibili e l'elenco degli attributi di ciascun tipo.

Attenzione, l'EAV è spesso visto come anti-pattern , perché può aggiungere più complessità a un programma rispetto a quanto in genere si aspetta. Quindi la mia raccomandazione è di usarlo solo per gli attributi del prodotto in cui hai veramente bisogno di quel tipo di flessibilità, gli "attributi definiti dall'utente", non per gli attributi comuni a tutti i tipi di prodotto. È perfettamente possibile implementare EAV solo in modo parziale o in una variante ridotta alle proprie esigenze. Ad esempio, è possibile fornire un determinato elenco di prodotti standard, ad esempio una "sedia base", una "tabella base", incorporata nell'applicazione e ogni attributo una riga classica nella tabella del database. Quindi lascia che l'utente crei qualcosa come una sedia da pranzo o una sedia da ufficio come estensioni della "sedia base", dandogli l'abilità di aggiungere gli attributi mancanti da solo (e solo quegli attributi diventeranno parte del modello EAV).