Nested Repeater på en meget OO måde

Er det sådan noget her du mener?

public class DataAccess
{
    public static List<OuterData> GetOuterData()
    {
        List<OuterData> outerList = new List<OuterData>();
        outerList.Add(new OuterData());
        outerList.Add(new OuterData());
        outerList.Add(new OuterData());
        return outerList;
    }
}

public class OuterData
{
    private string m_Text = "Outer Text";

    public string Text
    {
        get { return m_Text; }
        set { m_Text = value; }
    }

    public List<InnerData> InnerData
    {
        get { return GetInnerData(); }
    }

    public OuterData()
    {

    }

    protected List<InnerData> GetInnerData()
    {
        List<InnerData> innerList = new List<InnerData>();
        innerList.Add(new InnerData());
        innerList.Add(new InnerData());
        innerList.Add(new InnerData());
        return innerList;
    }
}

public class InnerData
{
    private string m_Text = "Inner Text";

    public string Text
    {
        get { return m_Text; }
        set { m_Text = value; }
    }
}

// og en repeater
<asp:Repeater ID="outerRepeater" runat="server" OnItemDataBound="outerRepeater_ItemDataBound">
  <ItemTemplate>
    Outer repeater<br />
    <asp:TextBox ID="otxt" runat="server" Text='<%# Eval("Text") %>'></asp:TextBox><br />
    <asp:Repeater ID="innerRepeater" runat="server" DataSource='<%# Eval("InnerData") %>'>
      <ItemTemplate>
        Inner repeater<br />
        <asp:TextBox ID="itxt" runat="server" Text='<%# Eval("Text") %>'></asp:TextBox><br />
      </ItemTemplate>
    </asp:Repeater>
  </ItemTemplate>
</asp:Repeater>

// og page_load
if (!IsPostBack)
{
    outerRepeater.DataSource = DataAccess.GetOuterData();
    outerRepeater.DataBind();
}

Mvh

Hej Snep...

Tak for din kommentar!

2 spørgsmål til ovenstående:

1. Er det den pæne måde at lave en nested repater på?

2. Hvordan håndtere du databindingen i "outerRepeater_ItemDataBound" (Der skal jo findes alle i innerData som har relation til den OuterData node den er kommet til)?

Hej c :o)

Jeg får innerdata med sådan en her på outerrepeateren:
DataSource='<%# Eval("InnerData") %>'

Men du kan self. også gøre sådan her:
protected void outerRepeater_ItemDataBound(object sender, RepeaterItemEventArgs e)
{
    OuterData data = e.Item.DataItem as OuterData;
    if (data != null)
    {
        Repeater innerRepeater = e.Item.FindControl("innerRepeater") as Repeater;
        if (innerRepeater != null)
        {
            innerRepeater.DataSource = data.InnerData;
            innerRepeater.DataBind();
        }
    }
}

Og er det den pæne måde at gøre det på.... Well... Det er én måde at gøre det på hvor selv bestemmer hvordan dine objekter skal være - i modsætning til den med dataset'et, hvor du lever under en generisk model som giver et vist overhead mv.

Du kan jo prøve at arbejde lidt med det, og se hvad du synes.... Som udgangspunkt kommer du til at skrive en del mere kode, hvis du skal kunne det samme med dine egne typer som du kan med et dataset (sortering, paging, editering...).

Mvh

Har du ikke selv nævnt engang at det er at fortrække at køre typestærkt så langt som muligt? :o)

Og hvad med alle de cast's der bliver lavet i selve repeateren, bør de ikke undgåes hvis det nu skal være helt fint?

:o)

Well... et typestærkt dataset er jo sådan set æhh... typestærkt, så den del af festen er jo for så vidt fikset i et rimeligt omfang.
Det man så kan klandre dataset'et for ville så være forhold omkring f.eks. footprint/performance og "cohesion" - hvor det måske egentlig er det sidste der normalt generer mig mest omkring det (sådan udfra et api-usability synspunkt).

Men jo - jeg kan godt lide at arbejde med mine egne typer ;o)

Hvad tænker du med mht. casts i repeateren?

Mvh

Havde lige gelmt den her, sorry...

Kan du uddybe lidt mere hvad problemet er med DataSet (måske knap så nørdet :))

Når jeg siger cast i repeateren mener jeg alle de her Eval("minværdi")

Hvis du i din applikation har brug for at arbejde med f.eks. enkeltpersoner, og lister af personer, kunne du vælge at oprette sådanne klasser:

public class Person
{
}

og

public class PersonCollection
{
}

Og du ville relativt nemt kunne finde ud af hvad de skulle kunne.

F.eks. ville et person objekt nok ha' en property som følger:
public string Cpr
{
  //...
}

Og din liste af personer ville nok give dig en mulighed for at finde en person i listen - baseret på cpr-nummeret.

Dine klasser ville så se sådan her ud:

public class Person
{
  public string Cpr
  {
    //... implementering
  }
}

og

public class PersonCollection
{
  public Person GetPersonByCpr(string cpr)
  {
    //... implementering
  }
}

Hvis du så har en liste af personer til rådighed i din applikation, kan du nemt, enkelt og intuitivt skrive koden til at finde en bestemt:

Person p = somePersonCollection.GetPersonByCpr("...");
og arbejde med den:
someLabel.Text = p.Cpr;

Og du har ikke 117 andre metoder/properties på dine objekter - der måske ikke er relevante for "dine" personer/personlister.

Den slags er rart at arbejde med, og når du dot'er i VS - får du kun ting at se, som giver mening for dig iht. det domæne du arbejder med.

Hvis du istedet arbejder med et generisk dataset - har du en bunke andre muligheder også, og ingen muligheder der er lige så "skarpe" som det ovenfor skitserede.
Det er normalt mindre fedt at arbejde med, og det er heller ikke typestærkt (med de fordele der nu kan være ved det).

Det typestærke dataset giver dig noget der i højere grad minder om det skitserede (men ikke helt), og du slipper ikke for "ekstra" properties/metoder.

DataSet's er ganske omfattende objekter, og de fylder godt i memory (har et stort footprint). Dine egne typer vil vanligvis være mere specialiserede - og ikke bære unødigt overhead.

DataSet har dog en bunke gode egenskaber som du får foræret - i modsætning til hvis du laver dine egne typer, hvor du må skrive koden selv (hvis der er behov for den).

Eval er ganske rigtig omkostningsfuldt, men det er der jo så meget der er.... Har du performanceproblemer med det?

Mvh

Det giver ganske god mening og er heller ikke nyt for mig men jeg må indrømme at have fortrænkt det :-) Det er sq så nemt bare at smide data i et dataset og rendere det ud via en repeater :O)

Men det kan jo hurtigt blive ret omfattende, hvis man hvergang man skal have data fra databasen skal lave et object med med de attrubuttre der er aktuelle og en collection til dette object.

Er det måden frem hvis man vil skrive pæn kode ?

Hvis du arbejder OO orienteret - vil du jo have en række af klasser der giver mening for din applikation under alle omstændigheder, og det er jo så bare dem du benytter dig af.
At de skal vises på skærmen en gang imellem er bare en detalje ;o)

"Pæn" er noget subjektivt :o)

Når man er færdig synes jeg det ser "pænt" ud, hvis man har en række af klasser man kan forstå/debugge/udvide/whatever så frit som muligt, og som for øvrigt har hensigtsmæssige relationer til hinanden.

Men altså - hvis du kan overdrage dit projekt i løbet af en formiddag, og vedkommende du overdrager det til på den tid får god forståelse af konstruktionen, og er i stand til at gå ned og rette/udvide umiddelbart, er det jo pænt og godt (nærmest uanset hvordan det så end er skruet sammen).

Mvh

Man tak for din kommentar smid svar så er der point