Trackback from dotnetomaniak.pl

Maciej Aniserowicz | String.ToEnum<>

Faaajne:) Uwielbiam takie małe i funkcjonalne kawałki kodu. Jest tylko jeden problem -- gdzie taki kod umieszczać? Kopiowanie go i wklejanie do każdego projektu mi się zbytnio nie podoba. Z drugiej strony tworzenie dll-ki z jedną lub kilkoma metodami też jest takie średnie. Z trzeciej zaś -- jedna wielka dll-ka, w której są wszystkie przyjemne "snippety" to też jakoś nie to. Masz w tej kwestii jakieś sprawdzone rozwiązanie?

Mały i elegancki helper ;) Bardzo lubie takie "zgrabne" rozwiązania!

@Procent
A czemu nie widzisz jednej duzej dll'ki? Rozumime zmienne dla aktualnego projektu ( bo sa jakos unikatowe) ale takie rzeczy jak dostep do danych (jesli masz) albo inne uzyteczne snippety/biblioteki ktore sie nie zmieniaja to czemu nie?

Pytam bo moze sa tam jakies za i przeciw ktory nie widze, bo zawsze ide Common.dll byla dla mnie akceptowala i uwazalem ja za dobra

Pozdrawiam.

Piszesz "Mając wartość enuma w postaci napisowej, pobraną na ten przykład z bazy" - jak się zapatrujecie na przetrzymywanie stringów zamiast wartości całkowitych w bazie ? Z jednej strony fajnie bo w bazie mamy czarno na białym konkretną wartość, z drugiej napis może się zmienić a wartość pozostanie wartością. I jeszcze kilka innych argumentów za jedną czy drugą stroną się znajdzie. To jak to jest u was i dlaczego ?

Jako, że nieraz borykałem się z: a) problemem dużego przyrostu wielkości bazy b) wydajnością - to jestem za używaniem liczb. Szczególnie, że często taki enum nie wykracza poza wielkość byte, a co za tym idzie tinyint w MSSQLu.

Czytelność bazy? Skoro baza to tylko zbiornik danych, a mięsko to kod programu to kto zagląda rękami do bazy? OK, raporty... trzeba czasami napisać skomplikowaną procedurę/zapytanie rękami, ale nie ma ich tak wiele, aby sobie z tym nie poradzić. Poza tym bardziej skomplikowany raport wymaga wcześniejszego przygotowania podłoża (czyli m.in. wyciągnięcie z kodu/dokumentacji (z naciskiem na dokumentację) znaczenia dla wartości enuma.

2) mamy jedną, nieustannie (siłą rzeczy) rozwijaną "instancję" biblioteki i każdy projekt ma do niej referencje (przez externals w svn czy submodules w gicie); ograniczając się jedynie do "przyrostowego" rozwijania biblioteki tego typu może być średnio wygodne, ponieważ w takich kawałkach kodu często mogą nastąpić zmiany (ciągle da się wymyślać lepsze sposoby na rozwiązanie częstych problemów); natomiast modyfikacja już napisanego kodu może zadziałać w jednym projekcie, ale popsuć wszystkie inne... w ten sposób nawet nasze wewnętrzne API musimy traktować jako de facto udostępniony na zewnątrz framework, a taki krok chyba najlepiej odsunąć w czasie tak daleko jak to możliwe

Właśnie taki framework, w zasadzie jedyny problem w nim to zależność od frameworka od MS.
Da się to spokojnie utrzymać przy użyciu svna. Rozwijane są tylko wersje zależne od .NET 2.0 i 3.5.
Co do psucia innych projektów, to raczej kwestia wychowania programistów i audytu kodu takiego frameworka.

To ja się podzielę implementacją ToEnum którą ja akurat wykorzystuje:

[DebuggerStepThrough]

public static T ToEnum<T>(this string target, T defaultValue) where T : IComparable, IFormattable

{

    T convertedValue = defaultValue;



    if (!string.IsNullOrEmpty(target))

    {

        try

        {

            convertedValue = (T) Enum.Parse(typeof(T), target.Trim(), true);

        }

        catch (ArgumentException)

        {

            // jakas tam obsluga

        }

    }



    return convertedValue;

}

To co lepsze? "where T : IComparable, IFormattable" czy "where TEnum : struct"

@Jacek

lepsze jest struct, ze wzgledu na to ze Enum nie moze byc klasa - jest typu value type i w systemie traktowany jest jako struktura (sa tylko dwie kategorie strutkrualne, enum i struct). Twoje rozwiaznie zezwala na przekazywanei obiektow - nie zaleznie jakie bys dodal tam interfejsy.

Przyklad:
public class Test : IComparable, IFormattable
{
public int CompareTo(object obj)
{
return 0;
}

public string ToString(string format, IFormatProvider formatProvider)
{
return base.ToString();
}
}

u Ciebie wywali to blad, u Procenta bedzie blad kompilacji - imo, lepsze rozwiazanie. Jedynym przypadkiem kiedy u Procenta moze pojawic sie blad to wtedy kiedy przekaze strukture ktora nie jest enum np.: int. Kompilator wtedy tego nie wykryje.

dodatkowo przechwytywanie bledu w takiej metodzie - nie jest dobrym pomyslem. lepiej by bylo napisac TryToEnum zwracajace bool i outowy enum. Lub poprostu wyrzucic wyjatek, ktory powinien zostac albo gdzies dalej zaalogwany albo wyrzucony uzytkownikowi (w zaleznosci od zapotrzebowania).


dodatkowo moze ty musiales miec w swoim rozwiazaniu wartosc domyslna zwracana, ja bym tego u siebie nie chcial, w szczegolnosci kiedy parsuje enum i to jeszcze na przyklad pobrany z bazy danych. Oznaczaloby to, ze ktos mi namieszal w danych w bazie i to nie jest dobry sygnal. Ale rozne sa wymagania wiec tez rozumiem ze takie cos moze byc przydatne, ale nalezy na to uwarzac :)

Gutek

@Procent
"Moim zdaniem nie ma "złotej reguły". Jeśli taki enum miałby być mapowany na najprostszą tabelę słownikową (id+nazwa) z kilkoma zaledwie elementami (np. stan zamówienia) to nie ma sensu tworzyć osobnej tabeli."
Możesz mieć jedną tabelę słownik i trzymać w niej takie rzeczy. Możesz przy zapisie do bazy rzutować na byte, przy odczycie na MyEnum. Pewnie można wymyśleć jeszcze wiele innych rozwiązań. W Twoim przypadku zmiana nazwy elementu enuma już zaczyna być problemem. A nigdy tak nie zrobiłem z powodów opisanych przez Dario-G.
Co do bibliotek, to przez większą część zawodowej kariery spotykałem się z (1) rozwiązaniem. Obecnie pracuję z (2), tylko nie externals w svn, a aktualizacja wersji biblioteki w projekcie następuje przy świadomym działaniu developera. Oddzielenie części kodu, który nie każdy może zmieniać i każda zmiana jest bardziej przemyślana niż zwykły commit jest wg mnie OK. I raczej w tej bibliotece nie ma takich drobiazgów jak pokazałeś.
A kod rzeczywiście zgrabny.

Artur