Zine.net online

4. Rozwiązanie z pogranicza czarnej magii. Według mnie nie najlepsze, gdyż możliwości atrybutów trochę zbyt nas ograniczają, poza tym trzeba jeszcze napisać kod, który odzyska zawarte w nich informacje.

3. Metoda pozwala tworzyć egzotyczne kombinacje trzech przekazywanych w konstruktorze parametrów. Stosując ją można doprowadzić do sytuacji, w której mamy w systemie dwa dokumenty tego samego typu, lecz o różnych identyfikatorach/nazwach.

2. Bez przykładu trochę ciężko mi sobie wyobrazić, o co tak naprawdę chodzi. Dyskutujemy tutaj na temat modelu obiektowego, a to, skąd pochodzą dane, jest sprawą drugorzędną. Jeśli cały sens tego rozwiązania polega na tym, że dane pobierane są z zasobów, to według mnie ciężko ustawić je w jednym rzędzie z pozostałymi.

1. Rozwiązanie proste i efektywne, ku któremu się skłaniam. Typ wyliczeniowy w sposób symboliczny reprezentuje różne rodzaje dokumentów, a dodatkowa klasa dostarcza związane z nimi metadane. Osobiście zaimplementowałbym to trochę inaczej, niż zaproponowałeś na początku tekstu:

public class DocumentTypeInfo

{

  public DocumentType DocumentType { get; private set; }

  public DocumentType Code { get; private set; }

  public DocumentType Name { get; private set; }

  private static readonly ReceiptInfo = new DocumentTypeInfo(DocumentType.Receipt, "PA", "Paragon");

  private static readonly InvoiceInfo = new DocumentTypeInfo(DocumentType.Invoice, "FK", "Faktura VAT");

  // Nie zezwalaj na tworzenie instancji klasy z zewnątrz.

  private DocumentTypeInfo(DocumentType documentType, string code, string name)

  {

     this.DocumentType = documentType;

     this.Code = code;

     this.Name = name;

  }

  public static DocumentTypeInfo GetDocumentTypeInfo(DocumentType documentType)

  {

     switch (documentType) {

        case DocumentType.Receipt:

           return ReceiptInfo;

        case DocumentType.Invoice:

           return InvoiceInfo;

        default:

           throw new InvalidOperationException("Could not create DocumentTypeInfo for document type '" + documentType + "'.");

     }

  }

}

.

.

.

// Pobierz metadane opisujące fakturę.

DocumentTypeInfo info = DocumentTypeInfo.GetDocumentTypeInfo(DocumentType.Invoice);

Wspomnę jeszcze, że formalnie najlepszą metodą jest ta, w której całkowicie rezygnujemy z typów wyliczeniowych na rzecz w pełni obiektowej reprezentacji rodzaju dokumentu - otrzymujemy wówczas coś na wzór enuma z Javy 5. Takie podejście pozwala m.in. na dodawanie nowych typów dokumentów do systemu bez potrzeby rekompilacji kodu. Z drugiej strony typ reprezentujący rodzaj dokumentu wymaga starannego przygotowania, m.in. zaimplementowania IEquatable<T> czy metody GetHashCode. Może się okazać (znając życie - najprawdopodobniej się okaże), że nigdy nie wykorzystamy zalet wynikających ze stosowania tego modelu i tylko niepotrzebnie stracimy czas. Z tego względu jestem zwolennikiem rozwiązania pomostowego, które sprawdza się wystarczająco dobrze.

Arek:

1. Jesli typ dokumentu jest poprostu jednym z atrybutow dokumentu jak data, kolor czy wartosc, czyli wplyw na zmiennosc widoku dokumentu jest znikomy (mowiac prosciej nie masz IFa na typie dokumentu, ktory powoduje zmiane sposoby wyswietlania dokumentu) - to nie zawracaj sobie glowy enumen bo to nic nie daje. Dla uzytkownika wartosc to czesc procesu biznesowego, a od strony kodu to poprostu kolejny dropek.

2. Jesli masz w kodzie jednak troche tych IFow czy na przyklad rodzaj/typ widoku zmienia sie pod wplywem Invoice/Receipt i masz logike w stylu: "jesli paragon to drukuj tekstowo i nie dodawaj do magicznej tabeli, a jak masz fakture to drukujgraficznie i zapisuje PDF", to uzyj enuma wszedzie gdzie sie da, a w "UI" dorob mapowanie enum<->info{ name,desc }. Dlatego ze jesli bedziesz chcial dodac nowy TYP dokumentu, to ... bedziesz musial zmienic logike lub dodac nowe IF/SWITCH dla nowego pola enuma.

3. Co do zmiany per klient wartosci tego czy owego, to wbrew pozorom to wygodna rzecz nie rekompilujac aplikacji, bo... po to powstaly resource aby mozna bylo je zmieniac (oryginalnie tlumaczyc, ale co przeszkadza tlumaczyc per lient a nie jezyk? ;-) ) bez kompilowania od nowa. To opcja najprostsza i najszybsza. Ja jednak jak bym mial czas i fanaberie, to zdefiniowalbym to jako staly slownik (staly wzgledem klienta), wrzucil do bazy i przy starcie ladowal takie mapowanie wszystkich slownikow (bo pewnienie jeden by sie znalazl w systemie). Rozwiazanie sprawdzone wielokrotnie (co najmniej 4 razy ;-) ). Zauwaz ze takei sliwniki sa "malo zmienialne" wiec mozna taka mape/cache uczynic persistowalna... (deserializacje pewnei bedzie szybsza niz pierwsze wzbudzenie strzalu do SQL :-) )