Un modello di progettazione per il binding di dati di un oggetto (con sottoclassi) al controllo utente di asp.net

Question

Un modello di progettazione per il binding di dati di un oggetto (con sottoclassi) al controllo utente di asp.net

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Ho una classe astratta chiamata Address e sto derivando tre classi; Indirizzo di casa, indirizzo di lavoro, indirizzo NextOfKin.

La mia idea è quella di associare questo a un controllo utente e basato sul tipo di indirizzo che dovrebbe associare correttamente al controllo utente ASP.NET.

La mia idea è che il controllo utente non sappia quale indirizzo presenterà e in base al tipo che analizzerà di conseguenza.

Come posso progettare una tale configurazione, in base al fatto che il controllo utente può prendere qualsiasi tipo di indirizzo e associare di conseguenza.

Conosco un metodo come: - Dichiara oggetti di classe per tutti e tre i tipi (Home, Lavoro, NextOfKin). Dichiarare un enum per contenere questi tipi e basato sul tipo di questo enum passato al controllo utente, creare un'istanza dell'oggetto appropriato in base all'iniezione del setter.

Come parte del mio design generico, ho appena creato una struttura di classe come questa: -

So che mi mancano molti pezzi nel design. Qualcuno può darmi un'idea di come affrontarlo in modo appropriato.

design design-patterns asp.net user-control

posta Rohith Nair 12.02.2013 - 20:27

fonte

3 risposte

Leggi altre domande sui tag design design-patterns asp.net user-control

Stampa lista di larghezza fissa ordinata per colonna Miglior design per l'UI di inserimento dati [chiuso]

score 1 · Answer 1

In generale, non dovresti. Il controllo utente dovrebbe legarsi a un tipo concreto.

Un approccio migliore sarebbe quello di avere i bit di indirizzo di base propri della propria classe, e quindi comporre 3 classi per i bit opzionali, ciascuno contenente una classe di indirizzo di base come membro. Il controllo utente può quindi posticipare il rendering dei bit di indirizzo a qualche sottocontrollo.

O meglio ancora, includi semplicemente i telefoni di casa / lavoro e i parenti più prossimi (e lasciali vuoti se non utilizzati). Non è che quegli elementi si escludano a vicenda (o dovrebbero essere comunque ...).

score 0 · Answer 2

Sembra un candidato per un Pattern strategico . In un approccio semplicistico, utilizzare i delegati per eseguire l'associazione in base al tipo.

È proprio come si dimostra nel diagramma in cui il punto del modello strategico è quello di incapsulare il comportamento, assicurarsi che la classe non faccia più di una cosa e usare Delega pattern per designare un'interfaccia specifica e calcestruzzi per eseguire una funzione specifica.

score 0 · Answer 3

Penso che la soluzione migliore sarebbe definire una classe astratta che rappresenta un indirizzo e il tipo di indirizzo:

public abstract class Address
{
    public abstract string Type { get; }
    public abstract IEnumerable<string> FieldLabels { get; }
    public abstract IEnumerable<string> FieldValues { get; }
};

da cui potresti derivare in questo modo:

public class HomeAddress : Address
{
    public string FirstLine { get; set; }
    public string ZipCode { get; set; }
    public override string Type { get { return "HomeAddress"; } }
    public override IEnumerable<string> FieldLabels
    {
        get
        {
            List<string> tmp = new List<string>();
            tmp.Add("First Line");
            tmp.Add("Zip Code");
            return tmp;
        }
    }
    public override IEnumerable<string> FieldValues
    {
        get
        {
            List<string> tmp = new List<string>();
            tmp.Add(FirstLine);
            tmp.Add(ZipCode);
            return tmp;
        }
    }
};

Ogni elemento della GUI può quindi essere passato a un oggetto come puntatore della classe base e recuperare e visualizzare il tipo di indirizzo e i campi dell'indirizzo.

Se ci sono campi che sempre appaiono in tutti tipi di indirizzo allora potrebbero essere definiti nella classe base con solo campi facoltativi / presenti in modo variabile recuperati attraverso IEnumerable proprietà.