Cykl chcielibyśmy zacząć od przyjrzenia się technologii .NET, w oparciu o którą zbudowaliśmy część desktopową aplikacji. Spośród typowych bibliotek tej platformy z których korzystaliśmy szczególnie dwie zasługują na szczególną uwagę: WPF i WCF.

WPF (Windows Presentation Foundation) to silnik graficzny bazujący na platformie .NET od wersji 3.0. Co takiego ciekawego jest w WPF, że postanowiliśmy użyć jej do naszej aplikacji? WPF daje nam ogromne możliwości co do kształtowania wyglądu aplikacji. msejf ma być niebanalny, a jeśli tak, to WPF jest naturalnym wyborem. Tworząc interfejs użytkownika praktycznie nie musimy się niczym ograniczać. Nie musimy martwić się o to, że nie będziemy w stanie przełożyć kreatywności naszych grafików na działającą aplikację.

Dla nas, programistów, WPF ma też inne zalety. Przede wszystkim, WPF zmienia całkowicie sposób implementacji aplikacji desktopowych, zbliżając się stylem do aplikacji webowych. Nasze aplikacje oparte są o wzorzec projektowy Model-View-ViewModel, co skutkuje przejrzystym i łatwiejszym w utrzymaniu kodem.

WCF to drugie w kolejności ciekawe rozwiązanie, w oparciu o które zbudowaliśmy klienta msejf. WCF (Windows Communication Foundation) to część .NET Framework’a, która dostarcza ujednolicony model programistyczny dla aplikacji opartych o usługi. Większości będzie się to zapewne kojarzyć z komunikacją z zewnętrznymi serwisami. My wykorzystujemy WCF do komunikacji międzyprocesowej. Technologia znakomicie sprawdza się w tej roli, upraszczając wymianę informacji między komponentami. Jej zastosowanie daje nam też duże możliwości łatwej zmiany konfiguracji oraz monitorowania pracy komponentów dzięki wbudowanym mechanizmom logowania.

Co jeszcze w msejf desktop zasługuje na szczególną uwagę? Zastosowaliśmy mnóstwo ciekawych  rozwiązań. Długo zastanawialiśmy się nad wyborem optymalnej architektury, co zaowocowało sprawnie działającą, łatwą w utrzymaniu i stabilną aplikacją. Na każdym etapie prac staraliśmy się trzymać najlepszych praktyk wytwarzania i projektowania oprogramowania.

msejf desktop to nie tylko ciekawe technologie, ale przede wszystkim innowacyjna aplikacja, a efekt końcowy naszych prac będzie można już wkrótce podziwiać.

źródło: blog.msejf.pl

W aplikacji w sekcji odpowiedzialnej za przechowanie predefiniowanych zmiennych globalnych (jak np. nazwa bazy, string wyświetlany w górnej belce aplikacji etc.) ustawiam sobie zmienną, określającą, czy użytkownik jest zalogowany (domyślnie ustawioną na false) oraz metodę pozwalającą zmienić wartość tej zmiennej:

public class GlobalAppVariables
{
    /// Globalna zmienna, której wartość jest ustwaiona na 1, gdy użytkownik się zaloguje.
    static int _logged = 0;

    /// Dostęp/zmiana wartości globalnej zmiennej _logged
    public static int Logged
    {
      get
      {
        return _logged;
      }
      set
      {
        _logged = value;
      }
    }
}

Samo logowanie polega na wywołaniu metody, która połączy się z bazą, sprawdzi, czy dla podanych parametrów istnieje wpis i na tej podstawie zwróci wynik pozytywny/negatywny, co z kolei pozwoli mi ustawić wartość zmiennej _logged w następujący sposób:

private void button1_Click(object sender, EventArgs e)
{
    object result = Queries.StartSession(this.loginTxt.Text, this.PasswordTxt.Text);
   //Queries to osobna klasa, w której przechowywane są metody odpowiedzialne za operacje na bazie
    if (result != null)
    {
        this.Close(); //zamknięcie okna logowania
        GlobalAppVariables.Logged = 1; // w tej chwili wiem, że już mam zalogowanego użytkownika
    }
    else
    {
       //info o nieudanym logowaniu
    }
}

Jeśli już mam zalogowanego użytkownika, mogę odblokować domyślnie wyłączone opcje, lub zrobić coś innego.
Jeśli nie potrzebujesz wymyślnego systemu logowania skorzystaj z przedstawionego sposobu. Jest on wystarczający dla wielu nieskomplikowanych aplikacji. AVE!

public class ControlGenerator
{
    /// Prywatna zmienna typu Form1
    private Form1 pf;
   //...
}

Następnie, konstruktor klasy musi posiadać takie przypisanie zmienej pf, aby wskazywała ona na referencję instancji mojej Form1 (trochę to może zamieszane, więc kawałek kodu wyjaśni, co miałem na myśli):

public ControlGenerator(Form1 f1)
{
  pf = f1;
}

Tak właśnie wygląda konstruktor, o którym była mowa, a jak to wygląda ‘na żywo’ jest ukazane poniżej.

W formie głównej aplikacji (Form1) po kliknięciu w jeden z przycisków powinny wygenerować się kontrolki, inicjuję więc obiekt klasy ControlGenerator w następujący sposób:

private void button1_Click(object sender, EventArgs e)
{
    ControlGenerator generate = new ControlGenerator(this);
   // właśnie tu do konstruktora przekazuje referencję do Form1 za pomocą this
}

Skoro moje połączenie klasa – forma jest już aktywne, to pora napisać metodę generującą kontrolki. Do owej metody powinna być przekazana informacja jak wiele kontrolek utworzyć. W poniższym przykładzie ograniczę się do wygenerowania TextBoxów z Labelkami zawartymi w GroupBoxie (które mogą być oczywiście dodatkowo osadzone na jakimś panelu, czy czymkolwiek się chce).
Gotowa funkcja prezentuje się następująco:

    public void GenerateRegisterControls(int number, string text)
    {
      int[] textboxes = new int[number];
      string[] labels = { "Imię", "Nazwisko", "PESEL", "Ulica", "Numer budynku",
                              "Miasto", "Kod pocztowy", "Województwo", "Telefon" };
      int i = 0, move = 0;

      //tworzę GroupBoxa, do którego wrzucę tworzone kontrolki (opis metody w następnym listingu)
      GroupBox box = GenerateGroupBoxControl(text); 

      foreach (int element in textboxes)
      {
        TextBox textbox = new TextBox(); //tworzę nowego TextBoxa
        Label label = new Label(); //tworzę nowy Label
        //lokalizacja TextBoxa
        textbox.Location = new System.Drawing.Point(200, 70 + move);
        textbox.Name = "textbox" + i.ToString();
        textbox.Size = new System.Drawing.Size(360, 20 + move); //wymiary TextBoxa
        //Rozmiar czcionki w TextBoxie - funkcja nie zostanie przedstawiona
        //w tym wpisie
        textbox.Font = SetFontForElement(40, textbox.Font);
        textbox.TabIndex = i;
        textbox.Visible = true;
        //automatyczna zmiana rozmiarów TextBoxa przy zmianie rozmiaru okna
        textbox.Anchor = AnchorStyles.Left | AnchorStyles.Top | AnchorStyles.Right;
        textbox.BorderStyle = BorderStyle.FixedSingle; //styl ramki
        //lokalizacja Labela
        label.Location = new System.Drawing.Point(20, 80 + move);
        label.Name = "label" + i.ToString();
        //nazwa Labela wzięta z wcześniej utworzonej tablicy stringów
        label.Text = labels[i];
        label.Font = SetFontForElement(28, label.Font);
        label.Size = new System.Drawing.Size(160, 28);
        label.Visible = true;

        box.Controls.Add(textbox); //dodaję do GroupBoxa utworzone TextBoxy
        box.Controls.Add(label); //dodaję do GroupBoxa utworzone Labele

        i++;
        move += 50;
      }
      //dodaję GroupBoxa z kontrolkami do panelu w kontenerze Form1
      pf.splitContainer1.Panel2.Controls.Add(box);
    }

Jak widać funkcja nie jest specjalnie skomplikowana, a tablicę z nazwami labelek można by przekazać jako parametr – jednak nie ma potrzeby w tym wpisie rozmieniać się na drobne. Tworzenie TextBoxów i Labelek można by dodatkowo zostawić osobnym funkcjom wywołanym w GenerateRegisterControls, jak np. GenerateGroupBoxControl, która wygląda następująco:

    private GroupBox GenerateGroupBoxControl(string text)
    {
      GroupBox box = new GroupBox();

      box.Name = "GroupBoxRegister";
      box.Text = text;
      box.Location = new System.Drawing.Point(1, 9);
      box.Size = new System.Drawing.Size(pf.splitContainer1.Panel2.Width - 20, pf.splitContainer1.Panel2.Height - 20);
      box.Anchor = AnchorStyles.Left | AnchorStyles.Top | AnchorStyles.Right | AnchorStyles.Bottom;

      return box;
    }

Samo wygenerowanie kontrolek po kliknięciu w jeden z przycisków wygląda następująco:

    private void button1_Click(object sender, EventArgs e)
    {
      ControlGenerator generate = new ControlGenerator(this);
      //9 TextBoxów i 9 Labelek, GroupBox będzie opatrzony tekstem Rejestracja
      generate.GenerateRegisterControls(9, "Rejestracja");
    }

Efekt:

Jeśli ktoś dopiero zaczyna swoją przygodę z C#, to informacje, które przedstawiłem z pewnością się przydadzą, albo przynajmniej wskażą drogę poszukiwań w google. AVE!

Jednak tak ogromne narzędzie ma jedną sporą wadę – trzeba mu poświęcić mu trochę czasu zanim stanie się ono użyteczne. W pierwszej kolejności po narysowaniu poprawnego diagramu klas chciałem wygenerować diagram DDL. Co z tego wszystkiego wynikło opisuję poniżej.

Opis zawiera uniwersalny sposób generacji DDL, jednak znacząco jest ukierunkowany na zgodność z symfony (zgodność nazw atrybutów, klas modelu itp.)

1. Utworzyłem nowy projekt:
   Klikając kolejno: File > New project wpisując nazwę pod którą będę trzymać plik projektu (wszystkie informacje zawarte są w pojedynczym pliku) kontynuowałem przyciskiem Zapisz.
2. Moim oczom ukazało się okno w którym mogę wybrać rodzaj diagramu który automatycznie chciałbym dołączyć do projektu. Zaznaczam jedynie Class, bo o eksporcie tego diagramy jest ten artykuł.



3. Po zatwierdzeniu modelu w przeglądarce projektu (Project Browser) ukazał się pakiet (package) o nazwie Class Model, a w nim przykładowy model klas. Usunąłem z niego zarówno folder Systems jak i Frameworks oraz zawartość diagramu. Teraz mogę przystąpić do właściwego projektowania diagramu klas. Metodą przeciągnij i upuść z okna narzędzi (Tools) przeciągnąłem interesujące nas elementy diagramu. Ja w przykładzie wykorzystałem taki diagram:



4. Teraz pora na transformacje na DDL. W przeglądarce projektu klikając na pakiet prawym klawiszem myszy mam dostępną opcję transformacji aktualnego pakietu (Transform Current Package). Zaznaczając wszystkie dostępne elementy oraz transformację DDL (określając docelowe miejsce położenia) korzystam z przycisku „Do Transform”. Po kilu sekundach został utworzony pakiet DDL wraz z jego diagramem.



5. W zasadzie w tym momencie mogłbym wygenerować z diagramu plik SQL gotowy do użycia w bazie danych, gdyby nie jedna niezgodność. Zauważmy, że utworzone klucze główne oraz obce są w formacie {nazwa}ID (kategoriaID, artykulID). Symfony posiada inną konwencję ({nazwa}_id). Aby poprawnie skonfigurować nazewnictwo skorzystałem z edycji szablonów transformacji.
6. Wybierając Setting > Transformation Templates otworzyłem edytor szablonów



7. Aby skonfigurować poprawnie nazwy identifikatorów tabel oraz nazwy kluczy obcych należy wyedytowałem dwa szablony: Class oraz Connector. Odnajdując linię:

   name=%qt%%CONVERT_NAME(className, "Pascal Case","Camel Case")%ID%qt%

   zmieniłem ją na następującą:

   name=%qt%%CONVERT_NAME(className, "Pascal Case","Underscored")%_id%qt%

   Zostaje do wprowadzenia w szablonie Connector dziesięć analogicznych zmian.

8. Po wykonaniu wszystkich zmian, ponownie przegenerowałem diagram DDL (jak w punkcie 4). W wyniku czego otrzymałem diagram zgodny z konwencjami symfony (wcześniej należy usunąć poprzedni diagram DDL w celu wygenerowania nowych, poprawnych nazw kluczy obcych:



9. Nareszcie to czego oczekiwałem od samego początku! Pozostaje skorzystać z Project > Database Engineering > Generate Package DDL, w którym zaznaczając Generate Primary/Foreign Key Constrains oraz określając plik wynikowy File Generation > Single File generuje za pomocą Generate plik sql. W tym momencie mam gotowy skrypt SQL do wczytania do bazy danych.
10. Co jednak jeśli nie chcielibyśmy tych wszystkich kroków wykonywać na każdej stacji klienckiej z Enterprise Architectem lub po prostu podzielić się ze znajomym wykonaną pracą? Nic prostrzego. Korzystając z Tools > Export Reference Data możemy zaznaczyć interesujący nas DDL_Transform_Template i wyeksportować go do pliku xml. Taki plik możemy wczytać w dowolnym momencie do każdej stacji klienckiej korzystając z Tools > Import Reference Data