Udvidet brug af valideringskontroller

Ligesom med alle andre kontroller ender man hurtigt med gerne at ville de eksisterende valideringskontroller i .NET - det er dog lidt spidsfindigt i forhold til andre kontroller.

Et scenarie som jeg stødte på for nylig var at jeg gerne ville have et sted at samle valideringslogik. Jeg ville gerne undgå at sprede regularexpressions ud på forskellige sider, som så alle skal opdateres hvis logikken skal ændres.

Udover at samle logikken ville jeg også gerne undgå at skulle bruge to kontroller for at sikre at et felt er udfyldt og lave valideringen.

Efter at have undersøgt forskellige muligheder kom jeg frem til at man har to anbefalelsesværdige muligheder hvis man vil lave egne valideringskontroller:

Enten kan man extende BaseValidator - en god idé derfra kan være at bruge reflector til at disassemble de eksisterende kontroller, og så sin validering fra bunden ud fra samme principper.

Ellers er et godt tip at extende CustomValidator, da den giver mulighed for at lave validering client- og serverside henholdsvis ved at håndtere et event, og ved at angive en JavaScriptfunktion. På den måde kan man meget let lade sin extendede kontrol generere noget JavaScript, og implementere noget serverside validering. Derudover indeholder CustomValidator mulighed for at angive om der skal valideres hvis et felt er tomt, så på den måde kan man let styre om et felt er påkrævet.

Ved at lave en extended validaringskontrol kan man f.eks. samle sine RegularExpressions i en resource file (.resx) og så lave en property på kontrollen hvor man kan sætte hvilken expression der skal bruges. Kontrollen kan så selv generere JavaScript og håndtere valideringen både client- og serverside. På den måde er det langt nemmere at opdatere hvordan eksempelvis en email valideres, da det blot kræver en ændring i en resource file.

Luk en databaseforbindelse med using

Et hurtigt tip: Man kan lukke sin databaseforbindelse ved hjælp af using. Man behøver ikke lave den klassiske try, catch, finally. Man kan gøre sådan:

SqlConnection conn = DB.GetConnection();
SqlCommand cmd = new SqlCommand();
cmd.Connection = conn;
cmd.CommandText = "SELECT .... osv.";
conn.Open();
using (SqlDataReader reader = cmd.ExecuteReader(CommandBehavior.CloseConnection))
{
  while (reader.Read())
  {
    // læs data fra readeren med reader.GetString(0) osv.
  }
}

MEN! Tro ikke det betyder man kan gøre sådan:

conn.Open();
using (conn)
{
  conn.ExecuteNonQuery();
}

Når ovenstående er udført vil din connection stadig være åben! Luk den explicit med conn.Close() i en finally, sådan:

SqlConnection conn = new SqlConnection(connStr);

try
{
  SqlCommand cmd = new SqlCommand();
  cmd.Connection = conn;
  cmd.CommandText = "INSERT INTO osv....";
  conn.Open();
  using (conn)
  {
    cmd.ExecuteNonQuery();
  }
}
finally
{
  if (conn != null)
  {
    conn.Close();
  }
}

Jeg taler af bitter erfaring ...

Den nemmeste måde at sortere objekter på

Der er masser af muligheder for sortering i .NET, men de er allesammen ret besværlige for mig. Jeg skal altid bruge dokumentation eller kigge i gammel kode for at lave en ny sortering. Det kræver delegates og dem vil jeg gerne undgå om muligt - også fordi de er skyld i at logikken unødvendigt bliver spredt ud over flere steder. Hvis logikken skal spredes vil jeg selv bestemme det.

Hvor tit har I haft en liste af objekter som bare skal standard-sorteres ud fra en bestemt property på objektet? Det burde være et simpelt metodekald - det kan man gøre med Reflection, men det giver ikke en effektiv sortering - i stedet kan man gøre som beskrevet her.

I mit eksempel har jeg et array af Person-objekter som har en Salary og sikkert også nogle andre properties. Jeg vil gerne sortere dem efter deres Salary.

Person[] persons = GetPeople();
int[] salaries = new int[persons.Length];
for (int i = 0; i < persons.Length; i++)
{
  salaries[i] = persons[i].Salary;
}
Array.Sort(salaries, persons);

Ja, tro det eller ej. Arrayet persons er nu sorteret efter Salary. Så nemt kan det gøres!

Ikke syntaktiske forskelle imellem VB og C#

Så er jeg kommet fra start med at kode VB og jeg er faldet over nogle overraskende forskelle på de 2 sprog som jeg ikke fandt da jeg googlede emnet tidligere.

Først og fremmest blev jeg overrasket over at det navn man giver et projekt i VB rent faktisk bliver til et namespace. Det kan godt give nogle overraskende konsekvenser, hvis man ikke er klar over det :-)

Derudover er der større forskelle på hjælpefunktioner i Visual Studio - det er som om de er forbigået lidt i VB. Refactoring delen mangler helt - inklusiv funktionen til at tilføje using/imports statements automatisk. Og IntelliSence halter desværre en smugle idet der skal mindre til at "forvirre" den - sådan at den enten viser en forkert liste eller slet ingen liste af valgmuligheder.

Ellers for lige at knytte en kommentar til det syntaktiske må jeg sige at det er lettere at skifte imellem sprogene end først antaget. Der gik ikke mange dage før jeg synes det ene er lige så let læseligt som det andet. Det er derfor med det i mente en smugle ærgeligt at der er de småfejl i Visual Studio.

Min overordnede konklution er derfor stadig at det er en form sag at skifte imellem sprogene, og det skal på ingen måde være afgørende for hvilke jobs jeg vælger fremover. Men med det sagt ville jeg hvis jeg skulle vælge foretrække C#, da sproget er bedre understøttet og giver mulighed for at lave ting man ikke kan i VB - med unsafe kode.