Er det lurt å kapsle mange parametere som er like inn i en struct

stemmer
4

I utgangspunktet har jeg noe sånt som følgende:

public string SomeDBMethod(string server, string dbName, string userName, string password,...)

Er det lurt å refactor det til følgende:

public string SomeDbMethod(DBParams parameters, ...)

Hvor DBParams er definert som følger:

public struct DBParams
{
  string Server {get;set;}
  string DbName {get;set;}
  string UserName {get;set;}
  string Password {get;set;}
}

Mitt poeng er egentlig å være i stand til å passere rundt færre parametre som jeg synes fungerer med lange parameterlister egentlig ganske stygge.

Jeg har også funnet ut at det er noen begrensninger på denne tilnærmingen: Hvis SomeDbMethod er å bli utsatt som en webtjeneste metoden, kan jeg ikke bruke DBParams struct som parameter (så langt min forståelse om emnet av web-tjenester går ... som ikke er veldig langt).

Så dette er for mye bryderi for liten nytte eller er jeg inne på noe her?

Publisert på 04/06/2009 klokken 09:58
kilden bruker
På andre språk...                            


5 svar

stemmer
4

Med mindre du faktisk trenger å passere rundt dette settet med parameteren veldig ofte (med samme data), ser jeg ikke noe behov. Lange parameterlister er ofte et tegn på et behov for å refactor koden, men så igjen er noen ganger uunngåelig. (I din situasjon er virker mer som sistnevnte.) Så, bare gå med grei metode for sending av parametrene direkte med mindre du befinner deg som ønsker å lagre parametersett (i hvert fall midlertidig) - du virkelig ikke vil spare noen kode ellers, og absolutt ikke øke lesbarheten.

Metoden bruker en struct pålegger ikke noen begrensninger i forhold til webtjenester. Du trenger bare å gjøre den typen som serial ( DataContracti WPF, tror jeg), og det bør ikke være noen problemer.

Svarte 04/06/2009 kl. 10:04
kilden bruker

stemmer
3

Jeg har alltid gruppe parametere som går sammen til ett enkelt objekt - koden er renere på denne måten, er det åpenbart at de er i slekt med hverandre og alltid brukes sammen.

Men i de fleste tilfeller bruker jeg en klasse og ikke en struct. Fordelene med structs var aldri klart for meg, og de er smerter i ryggen i mange situasjoner (jeg antar webservices scenario er bare ett eksempel).

Du kan lage en klasse uforanderlige hvis du ikke vil at folk skal endre det (om dette var grunnen til å bruke struct)

Svarte 04/06/2009 kl. 10:05
kilden bruker

stemmer
2

Det er et mønster som heter kapsle sammenheng som snakker om saker som er involvert med å bruke denne teknikken. Det kan være verdt å ta en titt på det for en detaljert analyse.

Svarte 04/06/2009 kl. 12:39
kilden bruker

stemmer
1

Jeg foreslår at du leser dette spørsmålet på structs vers verdier objekter

Nesten helt sikkert gjøre struct foranderlig er en veldig dårlig idé i dette tilfellet.

Gitt at navngitte parametre kommer i C # 4.0 Jeg vil foreslå noe som dette er rett og slett kommer til å være irriterende senere og bør unngås med mindre det er et stort behov for å passere om denne 'pakken' av informasjon på mange forskjellige skritt samt drift som kun mening på dem.

For å være ærlig hvis klassen / struct ikke opprettholde / håndheve noen invariant så er det lite poeng.

Svarte 04/06/2009 kl. 10:05
kilden bruker

stemmer
0

Du kan bruke Struct hvis du ønsker å kapsle relaterte variabler. Det trenger ikke å være et objekt. Som Structs er verdityper, i motsetning til klasser, de krever ikke haug tildeling, også de er vedtatt av verdi ikke med referanse lignende gjenstander.

IMHO i dette tilfellet å lage en klasse til å holde denne informasjonen ikke tilføre verdi, men hvis du har tenkt til noe mer sofistikert med DBParams informasjon (utsette det som et parameter for en Webservice), og deretter vurdere å bruke et objekt. Hvis du ønsker å bare passere disse parametrene i en konsis måte struct er ok.

Du kan få mer info her:

http://discuss.joelonsoftware.com/default.asp?dotnet.12.489354.15

Svarte 16/07/2009 kl. 13:43
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more