Obiekty biznesowe

Projekt neosowy składa się z obiektów biznesowych.

Obiekt biznesowy - to podstawowe pojęcie technologii NEOS. Zwykle odpowiada pojedynczej tabeli w BD, widokowi lub zapytaniu SQL. W ramach obiektu definiujemy elementy takie jak: pola, akcje, metody i formy. Można także tworzyć obiekty nie związane z danymi w BD, np. w celu tworzenia form nie związanych z żadnymi danymi. Każdy obiekt zdefiniowany jest w ramach jakiegoś projektu.

Rodzaje obiektów biznesowych

Obiekty biznesowe dzielimy następująco:

• obiekty fasady (wystawiające funkcjonalności projektu na zewnątrz tego projektu)

• obiekty dostępu do danych (źródło danych z tabeli). Takie obiekty mogą posiadać kod triggerów napisany w C# oraz inne metody logiki biznesowej skupione wokół tabeli, której dotyczy obiekt. Mogą także mieć okna, jeśli dane z tej tabeli podlegają bezpośredniej edycji.

• obiekty GUI (źródło danych z zapytania SQL lub z metody w C#). Takie obiekty zwykle służą do przeglądania danych gromadzonych z różnych źródeł i złożonych okien prezentujących te dane. Zwykle posiadają mało kodu logiki biznesowej, za to odwołują się do metod logiki obiektów dostępu do danych

• inne (obiekty bez źródła danych, analizy, źródła danych analiz, dashboardy)

Powiązane artykuły

• Standardy tworzenia obiektów biznesowych i pól modelu danych
• Źródła danych obiektu biznesowego
• Korzystanie z dziedziczenia obiektów biznesowych
• Zasady nazewnictwa obiektów biznesowych

Nowy obiekt

Jeśli chcesz dodać do projektu możliwość wglądu lub redagowania nowej tabeli albo możliwość oglądania wyniku nowego zapytania SQL wybierz funkcję Nowy -> Obiekt w oknie Neos Experta. Wypełnij dane podstawowe zgodnie z objaśnieniami w dymkach poszczególnych pól (co najmniej nazwę obiektu). Zaleca się alias bazy danych pozostawić pusty, gdyż wystarczy go określić we właściwościach projektu.

Nowy obiekt do tabeli

Jeśli zakładasz obiekt, którego zadaniem jest odzwierciedlenie tabeli lub widoku w bazie danych, to jako źródło danych wybierz "Dane z tabeli" i podaj jej nazwę w polu "Nazwa tabeli w BD". Następnie naciśnij Zapisz i nowo dodany obiekt pokaże się w drzewie w oknie struktury projektu.

Znajdź ten obiekt w drzewie struktury projektu i kliknij go. Ukaże się panel lub osobne okno, w którym będziesz mógł zdefiniować wszystko w ramach tego obiektu.

W pierwszej kolejności wypełnij dane na zakładce "Pola modelu danych", gdyż musisz określić, jakie pola posiada obiekt, aby zdefiniować okno. W przypadku obiektu z tabeli lub zapytania SQL, pola można wygenerować automatycznie przy pomocy funkcji Uzupełnij pola z BD. Pozostałe zakładki możesz na razie pominąć. Po wypełnieniu pól modelu danych możesz przejść od razu do zakładania nowej formy w tym obiekcie.

Nowy obiekt do zapytania SQL

Jeśli zakładasz obiekt do zapytania SQL, to zmień źródło danych na "Dane z zapytania" i wypełnij odpowiednie pola na zakładce "Dane z zapytania SQL". Przykładowe zapytanie analizujące tabelę KONTAKTY może wyglądać tak:

SELECT:

    select k.*

FROM / JOIN:

    from kontakty k

Jeśli aliasujesz podstawową tabelę zapytania wpisz ten alias w pole "Alias głównej tabeli". Dzięki temu nie będziesz musiał aliasować ręcznie wszystkich pól. Następnie naciśnij Zapisz i nowo dodany obiekt pokaże się w drzewie w oknie struktury projektu.

Pola modelu danych możesz wygenerować automatycznie podobnie jak w przypadku obiektu opartego na tabeli.

Pola obiektów pochodzących z zapytań wymagają zdefiniowania aliasu. Chodzi o to, że np pole REF w w/w zapytaniu SQL musi występować w postaci k.REF. Jeśli w definicji obiektu określiłeś alias głównej tabeli jako k to jest to aliasowanie domyślne i nie musisz nic więcej robić. Jeśli tego nie zrobiłeś, to pełną nazwę pola wraz z aliasem tabeli zapisz w "Nazwie źródłowej pola".

Jeśli zapytanie wykorzystuje kilka tabel, np:

SELECT:

    select k.*,c.*

FROM / JOIN:

    from kontakty k
    join cpodmioty c on c.ref=k.cpodmiot

to przyjmij, że tabela KONTAKTY jest główną tabelą i jej pola będą aliasowane domyślnie, natomiast niezbędne pola tabeli CPODMIOTY dopisz ręcznie do modelu danych i wypełnij nazwy źródłowe pól, np. dla pola NAZWA zapisz c.NAZWA.

Pamiętaj, że jeśli w polach modelu danych występują pola połączone przez relację do słowników, to Neos sam modyfikuje zapytania SQL poprzez dodanie konstrukcji left join do tabeli słownika dla wszystkich pól z relacją.

Aliasowanie obiektów biznesowych opartych o zapytanie SQL

Jeśli posiadasz obiekt biznesowy z zapytania SQL, ale dodasz na jakimś polu relację, możesz być postawiony w sytuacji, gdy nazwy pól wyniku zapytania pokrywają sie z nazwami pól obiektu słownika. W takiej sytuacji należy obiekt biznesowy uzupełnić o aliasy nazw pól. Dzięki temu pola staną się rozróżnialne. Aliasowanie należy zrobić w następujacych krokach:

1. W definicji obiektu biznesowego należy uzupełnić pole "Alias tabeli bazy danych", np wartością x (to jest nasz umowny alias).
2. Klauzulę Select * zamieniamy na Select x.*.
3. Przechodzimy przez wszystkie pola modelu danych i sprawdzamy, czy nazwa źródłowa pola otrzymała alias, czyli jest postaci x.POLE. Domyślnie pola modelu danych otrzymują aliasowanie automatycznie i nie powinno być potrzeby nic z tym robić. Jeśli któreś z pól nie ma aliasu lub ma inny alias, to możesz go poprawić lub wyczyścić. Wyczyszczenie przywraca domyślny sposób generowania aliasu pola.
4. Jeśli obiekt posiada metodę SetDBQuery(...) to musimy także dodać tam alias, np from PROCEDURA x.

Warning

W przypadku wykorzystania logiki biznesowej w celu dostępu do danych z obiektu opartego o zapytanie SQL, należy pamiętać o aliasowaniu pól modelu danych niepochodzących z głównej tabeli. Dla przykładu mamy obiekt oparty o zapytanie:

select 
    ecominventorystocks.*, 
    w.ktm, 
    w.nazwat, 
    w.nazwa, 
    w.ref 
    ei.wersjaref, 
    es.ecomstockid, 
    es.ecomchannelref, 
    ei.ecominventoryid
from ecominventorystocks
join ecomchannelstock es on es.ref = ecominventorystocks.ecomchannelstockref
join ecominventories ei on ei.ref = ecominventorystocks.ecominventoryref
join wersje w on w.ref = ei.wersjaref

Widać tutaj, że pole ecomchannelref pochodzi z tabeli ecomchannelstock. W przypadku wykorzystania kodu:

using(var stockLogic = new ECOM.LOGIC.ECOMINVENTORYSTOCKS())
{   
  var data = stockLogic.Get().Where(s => s.ECOMCHANNELREF == 1).FirstOrDefault();
}

Dostaniemy błąd z bazy danych Column unknown ECOMINVENTORYSTOCKS.ECOMCHANNELREF, ponieważ pole ECOMCHANNELREF nie znajduje się na tabeli ECOMINVENTORYSTOCKS. Neos nie potrafi się domyślić, z jakiej tabeli pochodzi dana kolumna i używa aliasu tabeli zdefiniowanego w obiekcie biznesowym. Aby poradzić sobie z tym błędem, należy wskazać, skąd pochodzi dane pole. Można to zrobić poprzez wypełnienie parametru nazwa źródłowa pola na definicji pola ECOMCHANNELREF na obiekcie ECOMINVENTORYSTOCKS, wskazując alias tabeli oraz nazwę pola tzn. es.ecomchannelref.

Należy to zrobić dla każdego pola niepochodzącego z tabeli głównej!

Obiekty modyfikowalne a obiekty tylko do odczytu

Tworząc obiekt masz możliwość wyboru w polu "Źródło danych", czy obiekt będzie modyfikowalny, czy tylko do odczytu. W przypadku obiektów modyfikowalnych domyślnie masz pełną możliwość edycji danych. Nawet jeśli nie zbudujesz okna edycyjnego, tabelę (grida) da się przełączyć w tryb edycji (F4), a o ochronę modyfikowalności pewnych pól musisz zadbać sam. W przypadku obiektów "tylko do odczytu" możliwość edycji jest całkowicie zabroniona we wszystkich kontrolkach.

Specjalnym przypadkiem obiektu jest obiekt "Dane z zapytania (modyfikowalne)". Mimo, że dane pochodzą z zapytania SQL a nie z tabeli, można w tym obiekcie dodawać nowe rekordy, modyfikować i usuwać. Jednak Neos w wersji starszej niż 6.0 sam nie potrafi zapisać tych modyfikacji, gdyż nie wie do jakiej tabeli i w jaki sposób. Należy w tym celu podziedziczyć metodę PostRecord(). Od wersji 6.0 pola należące do tabeli natywnej zapisują się automatycznie, a do zapisu pozostałych pól należy podziedziczyć odpowiednią metodę logiki biznesowej obiektu. Więcej na temat tego, jak zapisywać dane edytowane w takim obiekcie jest opisane w rozdziale dotyczącym tworzenia logiki biznesowej.

Obiekty bez źródła danych

Jeśli chcemy stworzyć obiekt, który w ogóle nie jest powiązany z danymi z bazy danych możemy stworzyć obiekt "Bez źródła danych". Taki obiekt nie może mieć pól modelu danych, może jednak mieć parametry i okna zawierające te parametry. W ten sposób możemy tworzyć interfejsy użytkownika, które w ogóle nie są połączone z bazą danych, lub są połączone nie wprost, np przez odpowiednie metody logiki biznesowej.

Obiekty oparte o programowe źródło danych

Są to obiekty, których dane nie są zasilane zapytaniem SQL do bazy danych ale metodą w C#. Ich szczegółowy opis znajduje się w rozdziale dotyczącym logiki biznesowej.

Pola modelu danych

Pola modelu danych są szczegółowym opisem pól zwracanych przez zapytanie SQL lub zawarte w tabeli powiązanej z obiektem. Najprościej jest uzupełnić pola automatycznie poprzez wywołanie funkcji Uzupełnij pola z BD dostępnej pod przyciskiem u góry okna. Funkcja ta przegląda tabele systemowe bazy danych oraz plik DBI leżący w podfolderze dbi serwera Neos w celu zaimportowania i wygenerowania najbardziej właściwego opisu pól. Opis ten nie jest jednak doskonały i dla wygenerowanej listy pól należy zweryfikować:

• Czy prawidłowo są wskazane pola klucza głównego. Jeśli nie - należy zaznaczyć właściwe pola.
• Czy wszystkie pola słownikowane posiadają "Domena BD" = "[Relacja]" oraz wskazanie do odpowiedniego obiektu słownika. Jeśli nie to należy założyć obiekt dla tabeli słownika i uruchomić funkcję uzupełniania pól z BD ponownie. Jeśli i to nie pomoże, to relację należy zdefiniować ręcznie poprzez zmianę pola "Domena BD" na wartość "[Relacja]" oraz wskazanie właściwego obiektu słownika oraz pola, po którym następuje złączenie.
• Czy pola mają prawidłowe etykiety. Jeśli nie, to należy je zredagować
• Czy pola mają pożądany domyślny sposób edycji. Jeśli nie, to należy go zmienić, przy czym pamiętajmy, że dla pola COMBOBOX nie związanych relacją ze słownikiem należy wskazać listę wartości, jakie pojawią się na liście rozwijanej.

Ponadto zwróć uwagę, czy niektórym z nowo utworzonych pól nie należy zdefiniować masek do walidacji danych oraz metod umożliwiających: nadanie wartości początkowej pola przy zakładaniu nowego rekordu, rekalkulacji wartości pola w zależności od innych pól oraz walidacji poprawności danych w polu. Jeśli pola modelu danych definiujesz ręcznie symbol pola pisz DUŻYMI LITERAMI bez spacji i polskich znaków, gdyż symbol pola jest używany jako identyfikator w języku C#.

Uwaga!

Jeśli wygenerowane etykiety pól mają przekłamania polskich znaków, upewnij się, że plik esystem.dbi leżący w folderze dbi serwera Neos jest zapisany w kodowaniu UTF-8.

Uwaga!

Pola modelu danych nie mogą być nazwane słowami kluczowymi lub nazwami używanymi jako klasy np. nazwa DB będzie kolidowała z namespacem Neos.Core.Database.DB, ponieważ jest on dodawany do sekcji using plików autogenerowanych .cs. Jak rozpoznać taki problem? Objawia się on błędem kompilacji CS1061 o przykłądowej treści : [ścieżka do pliku cs].cs(251,16): error CS1061: Element „DataFieldValue” nie zawiera definicji „GetDatabase” i nie odnaleziono dostępnej metody rozszerzenia „GetDatabase”, która przyjmuje pierwszy argument typu „DataFieldValue” (czy nie brakuje dyrektywy using lub odwołania do zestawu?).

Pola wyliczane

Do pól modelu danych możesz dodać pola wyliczane dowolnymi wyrażeniami SQL. Pola takie znajdą się w zapytaniu do tabeli, a więc możesz je wyświetlać w oknach i wykorzystywać w metodach C#. Jest to szczególnie przydatne w celu wygenerowania pola zwracającego ciąg znaków formatujący dane w tabelach.

Pola wyliczane w słownikach nie są obsługiwane i będą miały pustą wartość. Aby skorzystać z takiej funkcjonalności należy zmienić źródło danych obiektu na widok.

Pole używane w skryptach

Nie zaznaczenie tej flagi może powodować błędne działanie metod takich jak FindRecord(), FirstRecord(), czyli takich, w których argumenty metod przyjmują nazwy pól modelu danych. Wywołanie takiej metody w obiekcie A, dla obiektu B może sprawić, że taka metoda nie znajdzie danych pól, jeżeli nie są używane na formach obiektu B, lub jego metodach.

Przykład

Jest ustawione pole wyliczeniowe z kodem iif(De2ac32.SYMBOL is null,'=~=%C0xe699ff','') gdzie De2ac32 to alias na słownik z obiektu PRONAGZAM i w obiekcie użyta jest metoda:

using (PRONAGZAM orders = new PRONAGZAM()) 
{ 
if (orders.FirstRecord()) 
{ 
} 
}

Pole używane w selekcji

Od wersji 6.3 Teneum. Zaznaczenie tej flagi spowoduje dodanie pola przez klienta VCL do kolekcji SelectedRows dzięki czemu można użyć jego wartości w metodach neosowych. Od wersji 6.3 zaleca się usunięcie z klucza głównego pól sztucznie dodanych w celu udostępnienia ich przez kolekcję SelectedRows i zaznaczenie na nich powyższej opcji. Pola należące do klucza głównego powinny mieć tę flagę odznaczoną.

Flaga nie ma wpływu na klienta WEB. Użycie na kolekcji SelectedRows, powstałej przez zaznaczenie wierszy na gridzie w kliencie WEB, pola nie należącego do klucza głównego z zaznaczoną opcją: Pole używane w selekcji, spowoduje zgłoszenie wyjątku. W kolekcji SelectedRows znajdą się tylko pola należące do klucza głównego.

Logowanie zmian pola

Możliwe jest logowanie zmian wartości danego pola do bazy danych. Aby aktywować logowanie zmian należy w oknie właściwości pola zaznaczyć opcję "Logowanie zmian".

Każda zmiana wartości pola zostanie zapisana do tabeli SECURITY_LOG.

Ważne!

Obsługiwane (zapisywane) jest maksymalnie 5 kluczy głównych dla danego rekordu!

Relacje

Każde pole w modelu danych otrzymuje typ pola (VARCHAR, INTEGER, itp). Istnieje jednak specjalny typ o nazwie "[Relacja]", który oznacza, że dane pole jest łącznikiem do jakiegoś słownika. Po zaznaczeniu pola "Pole posiada relację do słownika", otwiera się panel umożliwiający wskazanie obiektu słownika i pola łącznikowego w słowniku (zwykle będzie to pole klucza głównego słownika). Tak zdefiniowana relacja daje deweloperowi następujące możliwości:

• Na formie można wstawiać kontrolki nie tylko dla pola własnego obiektu, ale także do wszystkich pól słownika w złączeniu przez to pole. A więc pola słownika dotyczą rekordu, który jest wskazany w polu, na którym zdefiniowano relację.
• W kodzie C# można odwoływać się nie tylko do pola bazowego dla relacji np. this.CPODMIOT, ale także do wszystkich pól słownika, np. this.CPODMIOT_NAZWA.
• Takie kontrolki mogą być redagowane. W przypadku zwykłych kontrolek typu EDIT, automatycznie pojawia się przycisk F3 umożliwiający pokazanie słownika i wybranie z niego wartości. W przypadku kontrolek typu COMBOBOX/DROPDOWN, słownik pojawia się w rozwinięciu COMBOBOX/DROPDOWN.
• Relacji można używać do szybkiego łączenia zależności master-detail między formami podczas zagnieżdżania form (np. nagłówki i pozycje). Taka relacja ogranicza zarówno dziedzinę wyświetlanych rekordów z tabeli detail (tworzy filtr), ale także inicjuje wartość pola relacji podczas dodawania nowego rekordu do obiektu detail w taki sposób, aby nowy rekord także mieścił się w dziedzinie. Jeśli takie pole jest umieszczone w formie edycyjnej obiektu detail, to takie pole staje się nieredagowalne.

Uwaga!

Zdefiniowanie relacji na danym polu nie zawsze powoduje, że można korzystać z kontrolek COMBOBOX, DROPDOWN a na oknie tego obiektu w tabeli lub drzewku będziemy mieli dostęp do pól pochodzących z tabeli słownika (np this.CPODMIOT_NAZWA). Dostępu do pól słownika nie mamy, gdy spełniony jest dowolny z poniższych warunków:

• obiekt słownika pochodzi z innej bazy danych

• obiekt słownika pochodzi z zapytania SQL lub z programowego źródła danych i nie ma wskazanej tabeli natywnej

• pole jest typu CHECKLISTBOX lub CHECKCOMBOBOX - gdyż wtedy pole w bazie danych jest ciągiem znaków i zawiera wskazanie do wielu rekordów ze słownika oddzielonych średnikiem (np "12;135;345")

Dodatkowe warunki złączenia

Jeśli potrzebujemy zdefiniować relację bardziej złożoną niż z jednego pola, to po zdefiniowaniu relacji można nacisnąć link Dodatkowe warunki złączenia, co powoduje otworzenie nowego okna, w którym można zdefiniować listę par pól, w ktorych jedno pochodzi z obiektu bieżącego a drugie z obiektu słownika. Dodatkowe warunki złączenia można tworzyć jedynie między polami obiektów (nie działa między parametrami). Dodatkowy warunek złączenia na pole słownika powoduje założenie kontekstu (filtru) na to pole. Filtr nakładany jest albo na podaną wartość stałą, albo na wartość jakiegoś pola z tabeli bazowej. Założenie w słowniku nowego rekordu powoduje automatyczne zainicjowanie wartości tego pola, tak aby poruszać się w specyficznej dziedzinie słownika.

Wybór wielu wartości ze słownika

Gdy używamy kontrolki typu EDIT, COMBOBOX, DROPDOWN ze słownika możemy wybrać tylko jedną wartość. Istnieje jednak możliwość wyboru wielu wartości ze słownika (tzw. wielowybór lub multiselekcja). Aby skorzystać z tej możliwości, należy:

• zdefiniować w obiekcie bazowym pole typu STRING, gdyż będzie ono przechowywać wiele wartości pola łącznikowego ze słownika, które to wartości będą oddzielone średnikiem. Np po wybraniu trzech wartości ze słownika pole może otrzymać wartość: 123;128;319
• zdefiniować na tym polu relację do słownika wskazując obiekt słownika i pole łącznikowe. Zwykle takim polem łącznikowym jest pole klucza głównego (np. REF).
• określić w modelu danych sposób edycji na CHECKCOMBOBOX lub CHECKLISTBOX. Jest to bardzo ważne, gdyż to od zdefiniowania sposobu edycji na polu modelu danych zależy to, czy Neos buduje w zapytaniu SQL o dane obiektu bazowego klauzulę left join SLOWNIK .... W przypadku wielowyboru nie można robić left joina do słownika, gdyż nie da się znaleźć właściwego jednego rekordu w słowniku.
• na oknie umieścić pole tak samo jak w przypadku innych relacji, czyli wyciągnąć pole i wskazać, które pole ze słownika ma się wyświetlić na liście kontrolki CHECKLISTBOX lub CHECKCOMBOBOX.

Uwaga!

W przypadku relacji wielokrotnego wyboru w kontrolce GRID i TREE nie da się wyciągnąć pola ze słownika (z uwagi na brak klauzuli left join do słownika). Możemy jedynie wyświetlić pole bazowe zawierające wartości pola łącznikowego oddzielone średnikiem.

Metoda na filtrację słownika

Do słownika stworzonego przy pomocy relacji można dodać metodę na filtrację słownika, która zawęzi jego dziedzinę. Gdy na obiekcie, z którego jest tworzony słownik, znajduje się kolejna relacja na obiekt, który posiada pola o tej samej nazwie co bazowy, to w kliencie WWW trzeba jawnie podać z jakiej tabeli ma być wzięte pole w metodzie na filtrację.

Przykład

public string FilterREL(WWW.GRID_DICT2 masterobject)
{
  return "WWW_GRID_DICT2.ID > " + ID;
}

Uwaga!

Należy zwracać uwagę na to, czy w każdym przypadku, niezależnie od wartości używanych parametrów, metoda na filtrację słownika zwraca poprawne wyrażenie SQL.

Uwaga!

Gdy korzystamy ze słownikowania, musimy mieć pewność, że klucz, po którym łączymy pole ze słownikiem, jest unikalny. Jeżeli klucz, po którym łączymy pole ze słownikiem, nie wystarcza aby jednoznacznie wskazać rekord słownika, wówczas należy dodać dodatkowy warunek złączenia. Nie można tego warunku zastąpić metodą na filtrację słownika.

Słownikowanie wartościami nie pochodzącymi z bazy danych

Czasami zachodzi potrzeba aby mieć możliwość wyboru wartości z jakiejś listy, ale ta lista nie pochodzi z bazy danych (np. lista dni tygodnia). Możemy to zrealizować w jeden z następujących sposobów:

• w polu modelu danych nie definiujemy relacji, ale określamy sposób edycji jako COMBOBOX, DROPDOWN, CHECKLISTBOX lub CHECKCOMBOBOX a następnie edytujemy listę wartości wybieralnych naciskając przycisk "Redaguj listę wartości". W oknie którym się pojawi możemy dla każdego elementu listy określić wartość, która będzie przechowywana w polu, wartość wyświetlaną oraz ikonę. Można także ręcznie określić kolejność elementów na liście. Wadą takiego rozwiązania jest to, że listy takiej nie da się filtrować, gdyż nie jest ona zwracana żadnym zapytaniem SQL. Takiej listy nie da się ponadto otworzyć w osobnym oknie do wyboru wartości, czyli w taki sposób w jaki jest słownikowana kontrolka EDIT.
• definiujemy relację na obiekt biznesowy posiadający programowe źródło danych (od wersji Neos 6.0). Wtedy w metodzie Fill(...) tego obiektu programowo tworzymy listę zwracanych elementów. Zaletą tego rozwiązania jest to, że kod może generować listę w sposób dynamiczny zależny od różnych parametrów. Możemy także taki słownik otworzyć w osobnym oknie i słownikować nie tylko kontrolki COMOBOBOX i DROPDOWN ale także EDIT. Wadą takiego rozwiązania jest to, że obiekt bazowy nie jest w stanie dodać klauzuli left join... do takiego słownika, a więc pola wyciągniętego ze słownika nie da się pokazać jako kolumnę GRIDa. Da się to zrobić tylko wtedy, gdy obiekt słownika ma wskazaną tabelę natywną, ale wtedy wracamy do sytuacji, gdy słownik jednak ma jakieś odzwierciedlenie w bazie danych
• jako słownik tworzymy obiekt biznesowy z zapytania SQL, w którym to zapytaniu nie odwołujemy się do żadnej tabeli w BD, ale zwracamy dynamicznie stworzoną listę rekordów, np tak:

  select 'Poniedziałek' from RDB$DATABASE
  union all
  select 'Wtorek' from RDB$DATABASE
  union all
  ...
  

  Zalety i wady tego rozwiązania są podobne do poprzedniego rozwiązania (czyli dla obieku biznesowego posiadające programowe źródło danych). Dodatkową wadą jest fakt, że takie zapytanie SQL jest specyficzne dla silnika bazodanowego, a zaletą jest to, że działa także dla starszych niż 6.0 wersji serwera Neos.

Powiązane artykuły

Więcej na temat relacji i słownikowania można przeczytać tutaj:

• Pokazanie okna słownika
• Zwracanie pól ze słowników w obiektach opartych o programowe źródło danych

Parametry

Parametry, to takie pola obiektu, które nie łączą się z żadnym polem w BD. Takie pola nie odnoszą się do żadnego pola żadnego rekordu w tabeli lub zapytaniu SQL, ale posiadają zdefiniowany sposób edycji i mogą być wyświetlane i redagowane na formach. Wartość parametru przechowywana jest niezależnie dla każdej instancji formy. Kilkukrotne uruchomienie tej samej formy tego samego obiektu biznesowego, może spowodować pokazanie jej na ekranie w kilku instancjach, a każda z nich będzie posiadała własne wartości parametrów. Kontrolki parametrów na formach nie są zbindowane z żadnym polem w tabeli. Serwer Neos przechowuje bieżące wartości parametrów, które pozostają niezmienne podczas chodzenia po rekordach, a zmieniać ich wartość można:

• jawnie kodem metod w C#
• redagując wartość w kontrolce na formie
• pisząc metodę na wartość początkową. Przy czym w odróżnieniu od pól danych, dla parametrów metoda na wartość początkową jest uruchamiana przed każdym pokazaniem nowej formy na ekranie. Dodawanie nowych rekordów do tabeli nie uruchamia tej metody.

Do parametrów można się odwoływać we wszystkich metodach, a zmiana wartości parametru odpala wywołanie metod zależnych od tego parametru, analogicznie jak dla pól danych. Powoduje to, że parametry mają wiele zastosowań. Przykładowe zastosowania to:

• Filtracja danych. Jeśli zdefiniujemy parametr, osadzimy go na formie (zwykle ponad tabelą) i napiszemy metodę na filtrację danych, która zależy od tego parametru (przypina się ją we właściwościach formy) to mamy gotowy mechanizm do szybkiej i wygodnej filtracji danych w oknie.
• Przekazywanie kontekstu do zagnieżdżania form. Podczas zagnieżdżania form, kod C# formy nadrzędnej nie może się odwoływać ani sterować bezpośrednio zachowaniem i wyglądem formy podrzędnej. Ale w metodzie na złączenie okna podrzędnego można ustawić wartości parametrów tego obiektu. Jeśli w obiekcie podrzędnym istnieją metody, które uzależniają wygląd formy od parametrów, to ustawienie wartości tych parametrów z poziomu obiektu nadrzędnego pośrednio steruje wyglądem formy. Jest to bardzo bezpieczna i elegancka metoda, gdyż parametry są niejako interfejsem danego obiektu i jego form na zewnątrz.
• Sterowanie wyglądem własnej formy. Jeśli chcemy na formie mieć np. checkboxa, który steruje pokazaniem i ukryciem jakiegoś panelu z kontrolkami na tej samej formie, to tworzymy parametr dla checkboxa, umieszczamy go na formie, a następnie do panelu, którym chcemy sterować przypinamy metodę na widoczność, której kod zależy od tego parametru. Takie rozwiązanie działa zawsze i niezależnie od tego czy klikamy na chceckboxa, czy nadajemy mu wartość początkową programowo. Działa także wtedy, kiedy dana forma jest osadzona jako podrzędna wewnątrz innej formy.