Best Practices: Hvordan sender dere data til og fra ett Options vindu

[Richard87]

Hei,

 

Har laget en del programmer og bruker som regel en Properties skjerm eller en slags custom Input vindu...

 

Men hver gang jeg gjør dette sender jeg data'en fram og tilbake på forskjellige måter, mesteparten som globale variabler, andre ganger som en egen klasse.

 

Men hva er 'rette' måten og gjøre dette på?

 

 

Takker for inspill

[MailMan13]

Dependency Injection

 

Koden som instansierer et vindu er også ansvarlig for å injiserer datamodellen som skal vises.

 

Generelt ønsker man bare avhengigheter èn vei, slik at når man først har instansiert en GUI-klasse vil man ikke at denne selv skal gå i parent, buisnesslaget eller utenfor sitt eget scope for å laste/lagre seg selv. Hvis koden som instansierer et nytt objekt også alltid laster og injeserer data som trengs og delegerer save/update-events dit det skal i buisnesslaget slipper man det.

Endret 10. mai 2010 av MailMan13

[Richard87]

Takker for svar, det hørtes jo ganske logisk ut...

[GeirGrusom]

I mitt databaseprogram har jeg et undo/redo system der property vinduet returnerer et objekt med funksjonspekere som endrer objektet (og som også har en rollback funksjon)

Her blir Perform funksjonen utført, og objektet blir dyttet på undo-stacken.

Det er en fordel fremfor å instansiere objekter ettersom det gjør det enklere å dele opp programmet ytterligere. Avhengighet skal en få så lite som mulig av.

[kgau]

Kanskje jeg misforstår, men om dette er i vb.net så burde det vel enkelt og greit:

 

Pass på at du ikke skriver dim, men public strWhatever as string og i den andre form'en så sender du inholdet fra en annen string ved å skrive: frmOptions.strWhatever = strOldThing

 

Unskyld om jeg misforstår og korrekt meg gjerne =)

[GeirGrusom]

Kanskje jeg misforstår, men om dette er i vb.net så burde det vel enkelt og greit:

 

Pass på at du ikke skriver dim, men public strWhatever as string og i den andre form'en så sender du inholdet fra en annen string ved å skrive: frmOptions.strWhatever = strOldThing

 

Unskyld om jeg misforstår og korrekt meg gjerne =)

Burde heller ha properties enn public variabler. Det er både av praktisk og estetiske grunner, blant annet så vil en ofte at utenforstående kode ikke skal ha direkte kontroll over data i en klasse.

 

Et eksempel:

 

Sett at du har en elev med mange fagkarakterer

 

Public Class Elev
 Public Class FagKarakter
   Public Navn As String
   Public Karakter As Integer
 End Class
 Public Karakterer As List(Of FagKarakterer)
 Public Navn As String
End Class

 

Nå er det fritt frem for hvem som helst å rette og/eller legge til karakterer som en vil. Derfor vil vi ofte at Karakterer eksempelvis skal være en Property som kun returnerer en IEnumerable(Of FagKarakter) som er dannet utifra en ReadOnlyCollection(Of FagKarakterer) fordi dette gjør det svært vanskelig for utenforstående kode å endre datasettet til Elev. Dersom du skal lage et API som andre enn deg skal bruke, så er det SVÆRT viktig at det ikke er mulig å bruke koden på en ikke tiltenkt måte, og da er det kjekt å ha properties og lignende fremfor å gjøre alt public.

Enkelt og greit: bruk Properties på alle egenskaper som skal brukes fra utsiden.

 

Vet ikke om det er i Visual Basic, men i C# ihvertfall har en automatiske properties, som ser slik ut:

public string Name { get; private set; }

som gjør at du slipper å skrive noe redundant kode. Dette i motestning til tilsvarende i c#:

private string _name;
public string Name { get { return _name; } private set { _name = value; } }

Kanskje det finnes noe lignende i VB, men jeg bruker ikke VB lenger.

[kgau]

Kanskje jeg misforstår, men om dette er i vb.net så burde det vel enkelt og greit:

 

Pass på at du ikke skriver dim, men public strWhatever as string og i den andre form'en så sender du inholdet fra en annen string ved å skrive: frmOptions.strWhatever = strOldThing

 

Unskyld om jeg misforstår og korrekt meg gjerne =)

Burde heller ha properties enn public variabler. Det er både av praktisk og estetiske grunner, blant annet så vil en ofte at utenforstående kode ikke skal ha direkte kontroll over data i en klasse.

 

Et eksempel:

 

Sett at du har en elev med mange fagkarakterer

 

Public Class Elev
 Public Class FagKarakter
   Public Navn As String
   Public Karakter As Integer
 End Class
 Public Karakterer As List(Of FagKarakterer)
 Public Navn As String
End Class

 

Nå er det fritt frem for hvem som helst å rette og/eller legge til karakterer som en vil. Derfor vil vi ofte at Karakterer eksempelvis skal være en Property som kun returnerer en IEnumerable(Of FagKarakter) som er dannet utifra en ReadOnlyCollection(Of FagKarakterer) fordi dette gjør det svært vanskelig for utenforstående kode å endre datasettet til Elev. Dersom du skal lage et API som andre enn deg skal bruke, så er det SVÆRT viktig at det ikke er mulig å bruke koden på en ikke tiltenkt måte, og da er det kjekt å ha properties og lignende fremfor å gjøre alt public.

Enkelt og greit: bruk Properties på alle egenskaper som skal brukes fra utsiden.

 

Vet ikke om det er i Visual Basic, men i C# ihvertfall har en automatiske properties, som ser slik ut:

public string Name { get; private set; }

som gjør at du slipper å skrive noe redundant kode. Dette i motestning til tilsvarende i c#:

private string _name;
public string Name { get { return _name; } private set { _name = value; } }

Kanskje det finnes noe lignende i VB, men jeg bruker ikke VB lenger.

 

Ikke dumt, men jeg tror jeg misforstod spørsmålet da. Jeg varierer litt hvordan jeg sender data, da noe er bra i noen tilfeller men elendig i andre. Takk for tipsene uansett =)

[HDSoftware]

En annen approach er å bruke et interface.

Sett at en FORM har følgende felter:

Navn STRING

Adresse STRING

postnr STRING

Poststed STRING

 

Set at FORMEN også har behov for å lese ut relaterte egenskaper, som f.eks. ordre. Da vil nødvendigvis også FORM'en ha en eller annen collection, f.eks. LIST

Ordre List<OrdreHoder>

 

Da kunne man rett og slett laget et interface som denne FORM'en alltid brukte

 

interface IKundeForm
{
 string Navn{get;set;}
 string Adresse{Get;set;}
 string Postnr{get;set;}
 string Poststed{get;set;}
 List<OrdreHode> Ordrehoder{Get;set;}
}

og er man tøff, og det er man jo, så lager man et interface til Ordrehoder også:
interface IOrdrehode
{
 int Ordrenrget;Set;}
 DateTime OrdreDato{get;set;}
 etc. etc.
}

og bruker det i form interfaces i stedet for List<OrdreHode> - slik:
List<IOrdreHode> OrdreHoder{get;set;}

Dermed vil du alltid være sikker på at programmet rundt vet hva som MÅ være til stede i formen. Du kan da ta interfacet rett inn i FORM definisjonen slik og dermed kan du utenfra gjøre spørringer rett i formen

 

public form EndreKunde : IKundeForm

{

...

}

 

Eller du kan bruke en konstruktør til å sende inn interfaces:

 

public EndreForm(IKundeForm pKundeRecord)

{

...

}

 

Fordelen er at du dermer skiller klassene fra hverandre slik at de ikek trenger kjenne hverandre i det hele tatt. Eneste du trenger å gjøre er å lage interfaces som har det minimumet av funksjonalitet du trenger og ikke noe annet.

 

Men dette er selvsagt bare et alternativ til alle de andre variantene altså ;-)

 

edit: Husk å implemetere interfacet på Kunde klassen også:

 

class KundeClass : IKundeForm

{

...

}

 

Når man ser det litt i perspektiv så ville det nok være naturlig å kansje kalle interfacet IKunde eller noe slikt. Er jo ikek sikkert det bare er en FORM som skal bruke denne

Endret 25. august 2011 av HDSoftware

[rozon]

Dependency Injection

 

Koden som instansierer et vindu er også ansvarlig for å injiserer datamodellen som skal vises.

 

Generelt ønsker man bare avhengigheter èn vei, slik at når man først har instansiert en GUI-klasse vil man ikke at denne selv skal gå i parent, buisnesslaget eller utenfor sitt eget scope for å laste/lagre seg selv. Hvis koden som instansierer et nytt objekt også alltid laster og injeserer data som trengs og delegerer save/update-events dit det skal i buisnesslaget slipper man det.

 

Et Options vindu er ikke vesentlig forskjellig fra et annet vindu.

 

Injisere nok data til at datamodellen kan lastes mener du vel? Om parent skal ha all kode for lasting/lagring kan du ende opp med veldig store parent klasser uten at det i praksis gir deg noe nytteverdi.

 

Eksempel, et grid med Elever og du dobbelklikker på en av elevene. Modellen med grid er jo parent, men det er ikke naturlig at denne inneholder kode for lasting/lagring av en elev.

 

Istedet vil du injisere en unik nøkkel til eleven og la neste kontroller/viewmodel laste data for eleven. Nå kan dette igjen inneholde data som ikke alltid vises. Eksempelvis når en lærer åpner skjema så får han opp en annen info enn en eleven selv vil få opp. Nå er det ikke naturlig at koden for lagring/lasting av eleven vist i lærermodus ligger på parent kontrolleren.

[FenrisC0de]

Kan vel bruker structer, eller Structures som det heter i VB.NET?

 

Public Structure IKundeForm
 Public Navn as String
 osv...
 osv..
End Structure

Endret 13. april 2012 av Untouchab1e

[GeirGrusom]

Problemet er vel ikke datastruktur, men sømløs kobling mellom instillinger og programoppførsel.