Do czego służy małpa w c# csharp?

Do czego służy małpa csharp?

Małpa charp ma 2 zastosowania:
1) Kiedy potrzeba zdefiniować stringa dłuższego niż na jedną linijkę (lub po prostu pociętego)

string txt = @"ala
ma 
kota";

Przy okazji w stringu z małpą csharp’pie jeśli użyjemy cudzysłowu \” to będzie go trzeba zamienić na podwójny „”

string txt =  "tytuł: \"Programista\"";
string txt = @"tytuł: ""Programista""";

2) Drugim zastosowaniem „małpa csharp” jest użycie zmiennych, które chcemy nazwać jak słowa kluczowe, np.:

string class = ""; // wygeneruje błąd podczas kompilacji
string @class= ""; // poprawnie

Bonus: bardzo dobrze jest używać małpy na początku stringów wtedy gdy tworzmy wzorce wyrażeń regularnych. Odpada nam pilnowanie znaków zaczynających się od „\”.

C# null

Czyli wszystko co chcielibyście wiedzieć o null w c# a NIE boicie się zapytać

Na wstępie trzeba napisać oczywistą oczywistość: NULL jest w C# wartością... pustą.
Null może wystąpić w typach referencyjnych jak i "wartościowymi" (Reference types / Value types). Do typów wartościowych można go przypisać na 2 sposoby:

int? i;

Nullable i;

Obie linijki robią to samo.

Dla typów referencyjnych będzie to po prostu:

Object o;

W kodzie bardzo często można zauważyć notoryczne sprawdzanie czy czasem jakiś obiekt nie jest nullem.

if (obj == null || i.HasValue) {
//...
}

inną techniką jest użycie ?? (dwa pytajniki)

Object result = obj ?? new Object()

znaczy: jeśli obj jest null, to podstaw pod result new Object();
Istnieje możliwość jeszcze takiego (pięknego) zapisu):

string result = value1 ?? value2 ?? value3 ?? String.Empty;

Nie jest to dobra praktyka tym bardziej, że jeśli gdzieś nie przewidzimy warunku wtedy dostaniemy po oczach wyjątkiem "nullreferenceexception". Dobrą obroną jest utworzenie "specjalnego przypadku" (Special case / Null object pattern). Całość sprowadza się do utworzenia podklasy, reprezentującej wartości "puste", np.:

class Osoba {
   string Imie {get;set;}
   string Nazwisko {get;set;}
}

tworzymy reprezentację "nullową/specjalny warunek":

class OsobaNull : Osoba {
   public OsobaNull() {
       Imie = "";
       Nazwisko = "";
   }
}

i tylko w jednym przypadku sprawdzamy null, tam gdzie pobieramy obiejkt typu osoba, jeśli tam wykryjemy nulla to zwracamy new OsobaNull() i nigdzie już nie potrzebujemy sprawdzać żadnych warunków. Kod się wykona ale będą tak ustawione wartości obiektu, że kod nic zlego nie zrobi i nie zakończy się błędem.

Entity Framework jak działa metoda Include [c#]

Niebezpieczeństwa w używaniu metody Include podczas budowania zapytań

Kiedy zaczynamy zabawę z Entity Framework'iem w .NET'cie wszystko wydaje się na prawdę proste. Piszemy co chcemy wyciągnąć za pomocą składni LINQ robimy np. wykonujemy zapytanie i już mamy wyciągnięte dane. Lecz do końca nie jest tak różowo jak się nam wydaje. Entity Framework ma taką naturę, że jeśli przestaniemy mu patrzeć na ręce bardzo szybko może nas wprowadzić w poważne tarapaty. Bardzo dobrym pomysłem jest zainstalowanie sobie darmowego Express Profiler i podglądanie jakie zapytania zostają wysyłane do bazy. Czasem na prawdę można się przestraszyć jakie potwory musi przetrawić baza. Począwszy od kilku zagnieżdżeń aż po kilometrowe SELECTy. Trzeba uważać w szczególności na metodę Include, która jest super narzędziem, lecz należy dołączać STARANNIE wyselekcjonowane dane. Trzeba uważać na długie ścieżki. Zamiast pisać

...Include("Osoba").Include("Osoba.Kraj").Include("Osoba.Kraj.Zdjecie")

lepiej jest:

.Include("Osoba.Kraj.Zdjecie")

Wygenerowane zapytanie jest mniejsze a im mniejsze tym lepsze. Dlatego też jeśli to możliwe obcinać SELECTy przez określenie jakie kolumny nas interesują .Select(p => .....)

Podstawy wyjatków w csharp [c#]

Krótko o podstawach wyjątków (exceptions) w c#

W samym .NETcie istnieje bardzo dużo zdefiniowancyh już wyjątków, które możemy użyć w naszej aplikacji. Dziś skupimy się wyłącznie na podstawowych informacjach. Każdy wyjątek dziedziczy po klasie Exception. Jest to klasa nadrzędna dla exceptionów. Schodząc niżej o jeden poziom następuje podział na: ApplicationException oraz SystemException.

SystemException - po tej klasie dziedziczą wszystkie systemowe (dotnetowe) wyjątki takie jak nasz "ulubiony" NullPointerException. Można w skrócie powiedzieć, iż są to wyjątki dla niskopoziomowych części systemu.

ApplicationException - dziedziczą po niej wyjątki rzucane w wysokopoziomowych częściach aplikacji. Jeśli piszemy jakąś aplikację to dobrze jest aby nasze customowe wyjątki właśnie po niej dziedziczyły. Np. przypuścmy wystąpiła w naszej aplikacji jakaś sytuacja wyjątkowa, wtedy rzucamy naszym własnym wyjątkiem np. CustomException, dziedziczącym po ApplicationException.

Cała moc exeptionów właśnie w hierarchii w ich łapaniu. Dawno temu kiedy jeszcze nie było wyjątków reagowanie na wyjątkowe sytuacje odbywało się przez zwracanie odpowiedniego kodu błędu. Można było się w tym pogubić.

Zobaczmy prosty przykład użycia:

class NameException : ApplicationException {}

//----
// jakieś linie kodu
// i dochodzi do sytuacji wyjątkowej
//----


try{

  if (string.IsNullOrEmpty(name)) {
   throw new NameException();
  }
}catch(NameException ex) {
 // tutaj przejdzie sterowanie
}
catch(ApplicationException ex){ 
 // tutaj nie przejdzie
}
catch(Exception ex) {
 // tutaj tez nie przejdzie
}

Jeślibyśmy rzucili zamiast NameException jakimś innym dziedziczącym po ApplicationException to by wpadło do drugiego catcha. Natomiast wyrzucony wyjątek dziedziczyłby zaraz po klasie Exception to by wpadł do 3 catcha.
Dlatego bardzo ważna jest hieriarchia aby odpowiednio móc przechwytywać i reagować na wyjątki.