TECHNICKÁ UNIVERZITA V LIBERCI
Fakulta mechatroniky, informatiky a mezioborových studií
Studijní program: B2646 Informační technologie Studijní obor: Informační technologie
Aplikování prostředí LabVIEW při návrhu databázové aplikace s využitím .NET
Applying the LabVIEW environment to database application design on .NET
Bakalářská práce
Autor: Jan Havlíček
Vedoucí práce: Ing. Roman Špánek, Ph.D.
Konzultant: Ing. Jaroslav Vlach
V Liberci dne 2.1.2012
3
Prohlášení
Byl(a) jsem seznámen(a) s tím, že na mou bakalářskou práci se plně vztahuje zákon č. 121/2000 Sb. o právu autorském, zejména § 60 – školní dílo.
Beru na vědomí, Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé bakalářské práce pro vnitřní potřebu TUL.
Užiji-li bakalářskou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do skutečné výše.
Bakalářskou práci jsem vypracoval(a) samostatně s použitím uvedené literatury a na základě konzultací s vedoucím bakalářské práce a konzultantem.
Datum
Podpis
4
Abstrakt
Tato bakalářská práce se zabývá metodami přístupu k databázi z programovacího prostředí LabVIEW s využitím Microsoft .NET Frameworku.
V první části se věnujeme dostupným databázovým klientům určeným pro prostředí LabVIEW. Analyzujeme jejich vlastnosti a technologie přístupu k databázím. Dále se v první části zabýváme komponentami .NET Frameworku a možnostmi využití .NET Frameworku v programovacím jazyku LabVIEW.
Druhá část pojednává o námi navrhnutém řešení databázového klienta, popisuje jeho vlastnosti, vnitřní funkcionalitu, ovládání a porovnává jeho rychlost s ostatními řešeními.
Klíčová slova
LabVIEW, Microsoft .NET Framework, ADO, ADO.NET, CodeDOM, CLR, XML Serializace
5
Abstract
This thesis deals with methods for accessing a database from the programming environment of LabVIEW using Microsoft. NET Framework.
In the first part we discuss available database clients designed for LabVIEW. We analyze their properties and access technology to databases. Furthermore, in the first part we are dealing with .NET Framework components and implementation options of .NET Framework to environment of LabVIEW.
The second part we look into our proposed solutions of database client, describes features, interior functionality, and compares speed to other solutions.
Keywords
LabVIEW, Microsoft .NET Framework, ADO, ADO.NET, CodeDOM, CLR, XML Serialization
6
Obsah
Prohlášení ... 3
Abstrakt ... 4
Klíčová slova ... 4
Abstract ... 5
Keywords ... 5
Obsah ... 6
Seznam obrázků ... 8
Seznam zkratek a pojmů ... 9
1 Úvod ... 10
2 LabVIEW ... 11
2.1 .NET Connectivity ... 11
2.1.1 Omezení ... 11
3 Microsoft .NET Framework ... 12
3.1 ADO.NET ... 12
3.1.1 Typed DataSet ... 13
3.1.2 SqlDataAdapter vs. TableAdapter ... 14
3.1.3 Table Mapping... 14
3.1.4 SqlCommandBuilder ... 15
3.2 ADO vs. ADO.NET ... 15
3.3 CodeDOM ... 15
3.3.1 Providers ... 16
3.3.2 Třídy CodeDOM ... 16
3.3.3 Compile Assembly ... 16
3.4 XML Serializace ... 17
3.4.1 Omezení ... 17
3.4.2 XSD Nástroje ... 17
4 Common Language Runtime (CLR) ... 18
4.1 Verze .NET Frameworku a CLR ... 18
4.2 Common Type System (CTS) ... 19
4.3 AppDomain ... 19
4.3.1 Assembly Versioning ... 19
5 Microsoft SQL Server ... 20
5.1 System Views ... 20
5.1.1 Information Schema Views ... 20
6 Současní databázoví klienti ... 21
6.1 SQL Client ... 21
6.1.1 Data Manipulation ... 22
6.2 LabVIEW Database Connectivity Toolkit ... 22
7 LabVIEW ADO.NET Database Framework ... 24
7.1 Schéma funkcionality ... 24
7.2 Porovnání s SQL Clientem ... 25
7.3 Database Mapper layer ... 27
7.3.1 Struktura tříd a metod ... 27
7.3.2 Mapování databázových relací ... 28
7.4 DataSet layer ... 28
7.4.1 Vygenerovaná struktura zajímavých typovaných tříd, vlastností a metod ... 29
7.5 TableAdapters layer ... 30
7.5.1 Parametry konstruktorů TableAdapter ... 30
7
7.5.2 Parametry metody Update() ... 31
7.6 Presentation layer ... 32
7.6.1 ColumnToField ... 33
7.7 Assembly layer ... 33
7.7.1 CodeDOM ... 34
7.7.2 Command-line interface (CMD) ... 34
7.7.3 Generování assembly v AppDomain ... 34
7.8 Testy rychlosti ... 35
7.8.1 Jak jsme testovali ... 35
7.8.2 HW a SW podmínky testů ... 35
7.8.3 Porovnání databázových klientů ... 36
7.8.4 Porovnání funkcionality ColumnToField ... 37
7.8.5 Zhodnocení výsledků ... 37
7.9 Přidání Frameworku ve formě DLL do LV projektu ... 38
7.10 Příklady použití Frameworku ... 39
7.10.1 Vyhledání prvku v tabulce podle ID ... 40
7.10.2 Vytvoření nového záznamu v tabulce a vrácení přiřazeného ID ... 40
8 Závěr ... 41
8.1 Možnosti rozšíření ... 42
9 Bibliografie ... 43
8
Seznam obrázků
Obrázek 1 - LabVIEW - Ukázka kódu *15+ ... 11
Obrázek 2 - .NET Framework [19] ... 12
Obrázek 3 - .NET Framework a CLR verze [21] ... 19
Obrázek 4 - SQL Client Class ... 21
Obrázek 5 - SQL Client – Ukázka kódu ... 22
Obrázek 6 - LabVIEW Database Connectivity Toolkit ... 22
Obrázek 7 - LabVIEW Database Connectivity Toolkit - ColumnToField ... 23
Obrázek 8 - LabVIEW ADO.NET Database Framework - Hlavní okno ... 24
Obrázek 9 - LabVIEW ADO.NET Database Framework - Princip funkcionality ... 25
Obrázek 10 - SQL Client - Konverze objektů ... 26
Obrázek 11 - SQL Client - Schéma ... 26
Obrázek 12 - LabVIEW ADO.NET Database Framework - Schéma ... 26
Obrázek 13 - Database Mapper - Struktura třid ... 27
Obrázek 14 – Struktura tříd, metod a vlastností typovaného DataSetu ... 29
Obrázek 15 - LabVIEW ADO.NET Database Framework - Connection to MS SQL Server ... 30
Obrázek 16 - tabulkaAdapter(dataTable)... 31
Obrázek 17 - tabulkaAdapter(dataTable, where) ... 31
Obrázek 18 - tabulkaAdapter(datatable, connetion) ... 31
Obrázek 19 - tabulkaAdapter(dataTable, connection, where) ... 31
Obrázek 20 - tabulkaAdapter.Update() ... 32
Obrázek 21 - tabulkaAdapter.Update(DataRow[] datarows) ... 32
Obrázek 22 - tabulkaAdapter.Update(string message, string caption) ... 32
Obrázek 23 - tabulkaAdapter.Update(string message, string caption) - Dotaz ... 32
Obrázek 24 - Funkcionalita ColumnToField ... 33
Obrázek 25 - LabVIEW .NET Connectivity Tookit ... 38
Obrázek 26 - Select .NET Constructor ... 39
Obrázek 27 - .NET Constructor - example ... 39
Obrázek 28 - Vyhledáni prvku podle ID ... 40
Obrázek 29 - AddRow and getID ... 40
9
Seznam zkratek a pojmů
FW - Framework
C# - Programovací jazyk C# [1]
LV - LabVIEW [2] [3]
Entity Framework - Databázová komponenta Microsoft .NET Frameworku [4]
ADO.NET - ActiveX Data Object for .NET [5] [6]
CLR - Common Language Runtime [7] [8]
CLS - Common Language Specification [7]
CTS - Common Type System [7]
CIL - oficiálně MSIL (Microsoft Intermediate Language) [7]
MDAC - Microsoft Data Access Components ADO - ActiveX Data Objects
ODBC - Open Database Connectivity COM - Component Object Model
OLE DB - Object Linking and Embedding, Database CMD - Příkazový řádek (cmd.exe)
DLL - Dynamic-link Library EXE - typ spustitelného souboru XML Serializace [9]
XML - Extensible Markup Language [10]
XSD - XML Schema Definition [10] [11]
CodeDOM - Code Document Object Model [12]
Toolkit - LabVIEW Database Connectivity Toolkit [13]
SQL Client - Databázový klient firmy Preciosa a.s.
Microsoft SQL Server - relační databázový server od firmy Microsoft Assembly - zkompilovaný zdrojový kód [7]
AppDomain - Aplikační doména [7]
DBNull - hodnota zastupující neexistující hodnotu v databázích
LabVIEW .NET Connectivity Toolkit - toolkit umožňující využití .NET komponent [2]
Typed DataSet - typovaná třída DataSet [5]
ConnectionString - textový řetězec specifikující připojovací informace k databázovému uložišti Dataflow - datový tok [2]
Namespace - jmeny prostor obsahující unikátní identifikátory např. tříd [1]
Generický kód - kód nezávislý na použitém typu proměnné [1]
Vzdálený pohled - aplikační dočasné uložiště dat (tzv. cache) reprezentované třídou DataTable
10
1 Úvod
Hlavním tématem bakalářské práce jsou metody přístupu k databázi z prostředí grafického programovacího jazyka LabVIEW od firmy National Instruments s využitím platformy Microsoft .NET Framework.
Tato bakalářská práce navazuje na moji předchozí ročníkovou práci, ve které jsem se zabýval jednotlivými komponentami Microsoft. NET Frameworku [14].
V první části této bakalářské práce si přiblížíme současná řešení databázových klientů na trhu, zmíníme řešení navrhnuté firmou Preciosa a.s. a seznámíme se s velmi důležitými komponenty Microsoft .NET Frameworku a dalšími potřebnými technologiemi k analýze a vytvoření databázového schématu.
V druhé části se budeme věnovat samotnému řešení databázového klienta, probereme jeho jednotlivé části, porovnáme rychlostní rozdíly s ostatními řešeními a nakonec si představíme několik příkladů jeho použití.
Pro porozumění této práce jsou předpokládány základní znalosti objektového programování jazyka C# [1] a grafického programovacího jazyka LabVIEW [2] [3].
11
2 LabVIEW
LabVIEW je grafický programovací jazyk označovaný jako „G“, který využívá principu datového toku (dataflow) a spočívá ve vykonávání grafických bloků v pořadí, které určí programátor propojením dílčích bloků spoji („dráty“) (Obrázek 1). Nespornou výhodou toho programování je velká podpora paralelního programování. Programovací jazyk LabVIEW byl původně navržen pro ovládání a získávání dat z vybavení laboratoře. V dnešní době programovací prostředí nabízí univerzální rozhraní pro širokou škálu technických zařízení, integruje technologii Plug-and-play pro rozhraní: USB, PCI, PXI, Wi-Fi, Ethernet, GPIB [15], nabízí rozsáhle možnosti analýzy dat a signálů, multiplatformní využití a už dávno neplatí, že jeho hlavní využití je pouze v laboratořích. Přesto, ale zůstává jeho hlavní pole působností především v práci se signálem a technickými prostředky. Proto i my se v této práci zaměříme na tento obor.
Obrázek 1 - LabVIEW - Ukázka kódu [15]
2.1 .NET Connectivity
LabVIEW nabízí velmi široké možnosti využití různých technologii třetích stran.
Patří sem i možnost využití tříd Microsoft .NET Frameworku (.NET Connectivity Toolkit).
2.1.1 Omezení
.NET Connectivity Toolkit má řadu omezení, která významně ovlivnila naši práci:
Nekorektní podpora .NET Framework 4.0, NI tento FW netestovalo [16]
Nepodporuje tvorbu instancí generických tříd a volání jejich metod [17]
Nepodporuje volání více verzí CLR (viz kapitola 4) v jednom programu [17]
Nepodporuje datový typ dynamic [17]
Nepodporuje výchozí hodnoty pro volitelné parametry [17]
12
3 Microsoft .NET Framework
Microsoft .NET Framework obsahuje dvě verze komponenty ADO.NET (viz Obrázek 2), které nabízí funkcionalitu pro přístup k datovým uložištím (např.: Microsoft SQL Server). První verze je označována pouze ADO.NET a naleznete ji ve vrstvě .NET Framework 2.0. Druhá verze je nazvaná ADO.NET Entity Framework a náleží do vrstvy 3.5. Nová verze zvyšuje úroveň abstrakce pomocí objektově-relačního mapování, které je, ale samozřejmě vykoupeno o něco pomalejší rychlostí. Podrobně jsme se těmto dvěma verzím věnovali v mé předešlé ročníkové práci [14]. V této práci se budeme zabývat aplikováním těchto vrstev do LabVIEW. Zmíníme se také o komponentě nazvané CodeDOM (viz kapitola 3.3) a zabrousíme do znalostí vrstvy Common Language Runtime (CLR)(viz kapitola 4). Komponenta CodeDOM na obrázku není přímo vyobrazena, ale je součástí komponenty „Base Class Library“ (Obrázek 2).
Obrázek 2 - .NET Framework [19]
3.1 ADO.NET
Komponenta ADO.NET poskytuje přístup k datovému uložišti, obdobně jako tomu je u Microsoft SQL Serveru, ale také nabízí možnost přistupování k těmto uložištím přes služby jakou je OLE DB, ODBC a XML. Struktuře této komponenty jsme se věnovali v ročníkové práci [14]. Nyní se budeme zabývat touto komponentou
13 podrobněji. Vysvětlíme si principy mapování položek datového uložiště, které využívá třída SqlDataAdapter a také si přiblížíme typovaný DataSet (viz kapitola 3.1.1), který je důležitou součástí výsledného řešení databázového klienta.
3.1.1 Typed DataSet
Typovaný DataSet [14] se vyznačuje modifikovanými vlastnostmi tříd DataTable [14] a DataSet podle odpovídajících zmapovaných hodnot zdrojového databázového schématu například na SQL Serveru.
Nejdůležitější modifikované vlastnosti třídy DataTable:
Název tabulky Názvy sloupců Datové typy sloupců
Přípustné hodnoty sloupců na základě integritních omezení Výchozí hodnoty sloupců
Auto inkrementace Unikátní příznaky
Modifikace se samozřejmě týká i DataSetu, kam patří tyto vlastnosti:
Název databáze
Relace mezi tabulkami A další
Takto typovaný DataSet bývá zvykem označovat <název_databaze>DataSet.
Nespornou výhodu zmíněného DataSetu tvoří typová bezpečnost celého schématu, která je zajištěna již na aplikační úrovni. Od programátora není vyžadována velká znalost databázového schématu, protože je zajištěna vzniklým modelem DataSetu.
V neposlední řadě může tento model zajištovat integritu dat na základě databázových relací. Uvedených výhod samozřejmě můžeme docílit pouze za podmínek, že bude dodržena shoda mezi oběma databázovými modely.
Designer produktu Microsoft Visual Studio generuje pro typovaný DataSet některé další rozšiřující funkce, kterým se budeme věnovat v kapitole: 7.4.1.
14 3.1.2 SqlDataAdapter vs. TableAdapter
Jak jsme již popsali v práci [14], třída SqlDataAdapter zajišťuje hlavní komunikaci mezi datovým uložištěm (SQL Serverem) a takzvaným „vzdáleným pohledem“.
Vzdálený pohled si můžeme představit jako aplikační dočasnou paměť („cache“) dat reprezentovanou třídou - DataTable [14] (dále jen vzdálený pohled). Úkolem SqlDataAdapteru je vykonávat dotazy SELECT, INSERT, UPDATE a DELETE na základě uživatelsky předdefinovaných vlastností tohoto Adapteru.
Jedná se především o vlastnosti:
Způsob mapování sloupců zdrojové database (viz kapitola 3.1.3)
Nastavení parametrů pro dotazy SELECT, INSERT, UPDATE a DELETE Nastavení typu připojení
Nastavení connectionStringu
Aby programátor uvedené vlastnosti nemusel nastavovat ručně, nabízí Microsoft Visual Studio průvodce, který umožňuje vlastnosti vygenerovat dle vašich předdefinovaných parametrů. Třídu SqlDataAdapter s vygenerovaným vlastnostmi je pak nazývána jako TableAdapter. Pro takto svázanou dvojici se ustálilo označení
<název_tabulky>Adapter a <název_tabulky>DataTable, kde název tabulky odpovídá tabulce v zdrojovém schématu. Uvedené názvosloví symbolizuje pevné svázání TableAdapteru s třídou DataTable. V naší bakalářské práci jsme toto označení zachovali pro obdobnou modifikaci třídy, přestože se už nejedná o adapter generovaný pomocí Microsoft Visual Studia. Důvodem je jednoznačné odlišení předdefinované třídy od obecné třídy SqlDataAdapter.
3.1.3 Table Mapping
Jedná se o mechanizmus, který nám dovoluje nastavit parametry pro způsob, jakým bude mapován SQL Result Set na objekty in-memory (tzv. „vzdálené pohledy“) [18].
SQL Result je objekt, který obsahuje výsledek dotazu SELECT vrácený třídou SqlDataReader [14]. SqlDataReader je využíván třídou SqlDataAdapter [14], konkrétně metodou Fill. Table Mapping se dělí na dvě hlavní skupiny. Skupinu, která slouží k mapování tabulek v cílovém DataSetu – Table Mapping a mapování sloupců těchto tabulek - Column Mapping. Obě tyto skupiny pracují na podobném principu a
15 dovoluji nám tzv. „přemapovat“ názvy tabulek a sloupců v DataSetu, od jejich původního názvu ve zdrojovém schématu.
3.1.4 SqlCommandBuilder
Třídě SqlCommandBuilder jsme se v práci [14] nevěnovali. Vyžití této třídy nastává při generování dotazů SELECT, INSERT, UPDATE a DELETE pro třídu SqlDataAdapter [14], která automatické generování těchto dotazů nepodporuje.
3.2 ADO vs. ADO.NET
Framework MDAC (Microsoft Data Access Components) zahrnuje technologie ADO a ADO.NET, které slouží pro přístup k různým datovým uložištím (SQL Server, Oracle, DB/2, MySQL). Komponenty tak tvoří samostatnou programovou vrstvu, která není závislá na datové implementaci uložiště. Pro svoji funkcionalitu využívají tzv. „drivery“ – technologie jako jsou například: ODBC, OLE DB apod. Drivery jsou zodpovědné za vlastní přístup k datovému uložišti. Základem technologie ADO je Component Object Model (COM), zatímco technologie ADO.NET je založena na Data Providerech [14] definovaných pomocí Common Language Runtime (CLR)(viz kapitola 4) [19].
Hlavní rozdíly mezi technologiemi ADO a ADO.NET najdete v následující tabulce (Tabulka 1). Mezi velké výhody technologie ADO.NET patří vzdálený pohled, jenž nabízí možnost vrácení změn dat na původní hodnoty před změnou – tzn. akceptování nebo neakceptování provedených změn uživatelem. V některých případech, ale může být tento robustní vzdálený pohled pro programátora také nevýhodou.
ADO ADO.NET
Způsob přístupu Připojený při práci s daty Vzdálený pohled (model dat)
Odpojený přístup Bez přístupu DataAdapter, DataSet
Podpora XML Omezená Plná
Předávání dat Binární XML
Kontrola integrity Není Podporována
Tabulka 1 - ADO vs. ADO.NET
3.3 CodeDOM
Code Document Object Model (CodeDOM) reprezentuje komponentu, která zajišťuje rozsáhlý obecný model tříd, pro generování zdrojového kódu, několika programovacích jazyků firmy Microsoft. Model nám nabízí kompletní zastoupení všech
16 programovacích struktur od namespace, tříd, vlastností třid a metod, bloku try přes podmínky if, cykly for a while. Velkou výhodou je nezávislost modelu, na konkrétním generovaném programovacím jazyku. Komponenta CodeDOM našla velkého uplatnění v této bakalářské práci při generování LabVIEW ADO.NET Database Frameworku (viz kapitola 7).
3.3.1 Providers
Objektový model není závislý na konkrétním generovaném jazyku, jak jsme již zmínili v předchozím odstavci. Dostáváme tak možnost výběru programovacího jazyku před vlastním generováním zdrojového kódu.
Mezi hlavními CodeDOM poskytovateli najdeme:
Microsoft.CSharp.CSharpCodeProvider Microsoft.JScript.JScriptCodeProvider Microsoft.VisualBasic.VBCodeProvider
3.3.2 Třídy CodeDOM
Následující seznam shrnuje, některé zajímavé třídy modelu CodeDOM, které jsme použili v naši bakalářské práci.
CodeBinaryOperatorExpression //binarni operator (==; !=) CodeCommentStatement //trida komentare
CodeConditionStatement //podminka if
CodeConstructor //konstruktor tridy
CodeIterationStatement //reprezentuje smycku for CodeMemberField //vlastnost tridy
CodeMemberMethod //metoda tridy
CodeMemberProperty //property tridy s get;set CodeMethodInvokeExpression //zavolani metody
CodeMethodReturnStatement //navratova hodnota metody CodeNamespace //deklarace namepsace CodeParameterDeclarationExpression //deklarace parametru CodePropertySetValueReferenceExpression //hodnotu "value" v set() CodeSnippetCompileUnit //vyraz pro prime kompilovani CodeSnippetExpression //literalni vyraz
CodeThisReferenceExpression //reference "this"
CodeTryCatchFinallyStatement //chraneny blok try, catch CodeTypeDeclaration //deklarace typu
CodeTypeReference //reference na typ
3.3.3 Compile Assembly
Komponenta CodeDOM umožňuje taktéž pomocí poskytovatelů (viz kapitola 3.3.1) zkompilovat zdrojový kód do knihovny (assembly), buď jako spustitelný soubor .exe
17 nebo Dynamic-link library DLL. Pro kompilaci naleznete v třídě například CSharpCodeProvider tyto metody:
CompileAssemblyFromDom CompileAssemblyFromFile CompileAssemblyFromSource
3.4 XML Serializace
Hlavním záměrem XML Serializace v Microsoft .NET Frameworku je konverze XML dat do Common Language Runtime (CLR)(viz kapitola 4) objektů. Konverze do těchto objektů vytváří podmínky pro jednodušší zpracování v běžném programovacím jazyce. Microsoft .NET Framework podporuje serializaci objektů do schématu XSD (XML Schema Definition) dle specifikace W3C [20]. Pokud tedy vytváříme třídu, máme dvě možnosti, buď budeme programovat třídu ve standardním programovacím jazyce, nebo ji můžeme navrhnout v XSD schématu a následně schéma deserializovat do běžného kódu pomocí XSD Nástrojů (viz kapitola 3.4.2). Tento postup má jistá omezení, o kterých se zmíníme v následující kapitole: 3.4.1.
3.4.1 Omezení
Nepodporuje serializaci kódu s přístupovým oprávněním (např.: exception) [20]
Nepodporuje typová omezení kromě enumerace [20]
Nepodporuje vnořené namespace [20]
Nepodporuje parametry konstruktoru
3.4.2 XSD Nástroje
Pro konverzi XSD Schématu nebo DataSetu do zdrojového kódu tříd lze použít XSD nástroje, které naleznete v níže přiloženém seznamu. Zmíněné nástroje samozřejmě nabízí i zpětnou konverzi assembly do XSD Schématu. První nástroj nazvaný XML Schema Definition Tool (xsd.exe) je dodávaný s Microsoft Windows SDK. Zbylé nástroje jsou od třetích stran.
XML Schema Definition Tool (xsd.exe) XSDObjectGen
XML Data Binding for .Net XSDTidy
18
4 Common Language Runtime (CLR)
Runtime CLR zajišťuje jazykově neutrální platformu pro spouštění .NET aplikací.
CLR zastává funkce, jako jsou například: správa paměti, načítání assembly, bezpečnostní omezení, správa výjimek anebo synchronizaci vláken. Neutrálnost platformy nám dnes nabízí rozsáhlé možnosti integrace do různých produktů: Microsoft SQL Server 2005, IIS, Internet Explorer a další. Neutrálnosti bylo dosaženo pomocí překladu (kompilace) běžného programátorského jazyka (C#, C++, Visual Basic) do mezikódu nazvaného CIL (oficiálně MSIL - Microsoft Intermediate Language).
Jedná se o nejnižší úroveň pro člověka čitelného kódu. Kód CIL je vykonáván pomocí runtimu CLR. Překlad pro každý programovací jazyk zajišťují separátní kompilátory (např.: C# (csc.exe), Visual Basic (vbc.exe)).
4.1 Verze .NET Frameworku a CLR
Platforma Common Language Runtime (CLR) je obsažená v každé verzi .NET Frameworku spolu s dalšími hlavními knihovnami. Důležité je si uvědomit, že verze .NET Frameworku se ve většině případů neshoduje s verzí CLR. Pro běh aplikací není nutné instalovat předchozí verze .NET Frameworku ani CLR, protože každá verze obsahuje nezbytné komponenty. V programovém kódu lze zjistit verzi CLR pomocí vlastnosti Environment.Version nebo pro každou spuštěné aplikaci pomocí příkazu:
"%programfiles%\Microsoft SDKs\Windows\v6.0A\Bin\clrver.exe" –all
Verze jednotlivých frameworků a jejich CLR komponent jsou zobrazeny na obrázku (viz Obrázek 3), můžete zde také sledovat implementaci jednotlivých verzí do operačních systémů Microsoft Windows.
19
Obrázek 3 - .NET Framework a CLR verze [21]
4.2 Common Type System (CTS)
Jedná se o specifikaci definující pravidla, která musí programovací jazyky dodržovat, aby tak dovolovala komunikaci s dalšími jazyky, zajišťovala objektové orientovaný model, typovou bezpečnost, viditelnost objektů navzájem a efektivní vykonávání kódu.
4.3 AppDomain
Primárním účelem aplikační domény (AppDomain) je zajistit izolaci aplikace.
Aplikační doménu si můžeme představit jako logický kontejner pro skupinu assembly.
Ve výchozím stavu je pro každý EXE soubor vytvářen separátní adresový prostor, který obsahuje právě jednu aplikační doménu. Každý EXE nebo DLL soubor může obsahovat více assembly například: System.dll a další. Aplikační doména je vytvářena pomocí CLR a zaniká pouze s Windows procesem.
4.3.1 Assembly Versioning
CLR vytváří pro každé assembly informace o verzi, které slouží k jejich identifikaci.
Verze assemblies, na kterých je aplikace závislá, jsou uchovávány v manifestu. Obecně je aplikace spuštěna pouze s verzí, pod kterou byla sestavena a testována.
Mezi informace o verzi patří: číslo verze assembly, jazyková verze a dodatečné textové informace, které slouží pro informační účely. Číslo verze je využíváno pomocí runtime CLR a slouží k identifikaci assembly a částečně i procesu.
20
5 Microsoft SQL Server
Microsoft SQL Server je relační databázový server vyvinutý firmou Microsoft.
V této práci si představíme pouze jeho funkcionalitu System Views, která byla při mapování databáze pro LabVIEW ADO.NET Database Framework velmi nezbytná a užitečná.
5.1 System Views
Microsoft SQL Server nabízí kolekci systémových pohledů (metadat). V metadatech jsou obsaženy informace o tabulkách, pohledech, sloupcích, procedurách, oprávněních a další informace o každé databázi na SQL Serveru.
5.1.1 Information Schema Views
Information Schema je jedena z konkrétních pod-kolekcí metadat, která uchovává informace mj. o databázovém schématu. Patří sem tabulky s metadaty, které můžou výrazně ulehčit mapování databázového schématu, jako tomu bylo v případě našeho LabVIEW ADO.NET Database Frameworku (viz kapitola 7.3). Následuje seznam vybraných významných matadatových tabulek obsažených v sekci Information Schema (podrobnosti naleznete na webu) [21]:
COLUMNS
CONSTRAINT_COLUMN_USAGE KEY_COLUMN_USAGE
REFERENTIAL_CONSTRAINTS SCHEMATA
TABLE_CONSTRAINTS TABLES
VIEW_COLUMN_USAGE VIEW_TABLE_USAGE VIEWS
21
6 Současní databázoví klienti
V této kapitole se budeme věnovat současným řešením jednotlivých databázových klientů určeným pro vývojové prostředí jazyka LabVIEW (LV).
6.1 SQL Client
SQL Client se v současné době řadí k nejpoužívanějšímu řešení firmou Preciosa a.s.
Důvodem je nevyhovující funkcionalita LabVIEW Database Connectivity Toolkit (dále toolkit)(viz kapitola 6.2) dodávaného firmou National Instruments. Zmíněná skutečnost přivedla firmu Preciosa a.s. k navržení nového databázového klienta, který odstranil některé nedostatky toolkitu a také rozšířil funkcionalitu o nové potřebné komponenty.
Klient byl navržen jako LV třída se sadou funkcí (Obrázek 4) v prostředí LabVIEW.
Hlavní změna byla prodělána v použití jiné, novější, technologie ADO.NET, oproti toolkitu, který dosud využíval technologii nazvanou ADO. Rozdíly mezi těmito technologiemi najdete v kapitole: 3.2 ADO vs. ADO.NET.
Obrázek 4 - SQL Client Class
22 SQL Client má samozřejmě i své nevýhody, ale těm se budeme věnovat později.
Na dalším obrázku (Obrázek 5) můžete najít příklad použití SQL Clienta v LV kódu.
Obrázek 5 - SQL Client – Ukázka kódu
6.1.1 Data Manipulation
Blok nazvaný Data Manipulation (viz Obrázek 5) zastává funkcionalitu ColumnToField, které se budeme věnovat v odstavci: 7.6.1. Pro zatím jenom zmíníme, že se jedná o funkcionalitu, která zajišťuje, jak název napovídá, získání dat celého sloupce v podobě typovaného pole základního datového typu například System.Int32.
6.2 LabVIEW Database Connectivity Toolkit
Jedna se o toolkit (Obrázek 6) navrhnutý firmou National Instruments.
Obrázek 6 - LabVIEW Database Connectivity Toolkit
23 Pro přehlednost se pokusíme shrnout hlavní vlastnosti toolkitu v bodech:
ADO technologie [13]
Cena toolkitu: 22 190 CZK [13]
Nepodporuje hodnotu DBNull nebo její výchozí nahrazení
Nenabízí uživateli „vzdálený pohled“ reprezentovaný třídou DataTable [14]
dostupný v technologií ADO.NET (více o rozdílech mezi technologiemi v kapitole 3.2)
Na dalším obrázku je ukázka kódu funkcionality ColumnToField s využitím toolkitu.
Obrázek 7 - LabVIEW Database Connectivity Toolkit - ColumnToField
24
7 LabVIEW ADO.NET Database Framework
Obrázek 8 - LabVIEW ADO.NET Database Framework - Hlavní okno
Na základě analýzy (viz kapitola 6) jsme došli k závěru, že současná řešení databázových klientů jsou sice funkční, ale v některých ohledech nedosahují potřebné funckionality, ba jsou přímo omezující. Proto jsme navrhli nové řešení nazvané LabVIEW ADO.NET Database Framework (dále Framework), který si klade za úkol odstranit nedostatky současných klientů.
Omezení LabVIEW .NET Connectivity Toolkitu, o kterých jsme se zmínili v kapitole č. 2.1.1, nám neumožnilo implementovat současně nejvyšší vrstvu .NET Frameworku nazvanou ADO.NET Entity Framework. Nejvyšší vrstva by nám mohla nabídnout objektově-relační mapování ORM [14]. Na základě této skutečnosti jsme byli nuceni k vytvoření svého jednoduchého databázového mapperu s objektovým modelem databáze. Mapper jsme postavili na nižší vrstvě ADO.NET [14] podporované prostředím LabVIEW.
Omezení .NET Connectivity Toolkitu a nedostatky SQL Clienta nás také donutili k přesunutí programové části Framework do DLL assembly. Více o nedostatcích SQL Clienta se dozvíte v kapitole nazvané: 7.2 Porovnání s SQL Clientem.
7.1 Schéma funkcionality
Na následujícím obrázku (Obrázek 9) je znázorněna funkcionalita LabVIEW ADO.NET Database Frameworku.
25 Pomocí červené barvy je zde znázorněna vrstva „Database Mapper“, která slouží k mapování databázového schématu na SQL serveru (více o Database Mapperu v kapitole 7.3). Modrá symbolizuje bloky reprezentující jednotlivé vrstvy Frameworku.
Výstupem čtveřice vrstev jsou soubory zdrojového kódu s příponou .cs, které obsahují vygenerovaný kód pomocí .NET komponenty CodeDOM (viz kapitola 3.3).
Poslední blok s názvem „Assembly Builder“ je určený pro zkompilování jednotlivých vrstev do výsledného DLL assembly (více v kap.: 7.7 Assembly layer). Názvy souborů CS byly před úvodní tečkou zkráceny o počáteční řetězec <nazev_database>DataSet pro přehlednost grafu. Soubory jsou Frameworkem dočasně generovány na cestě
%temp%\LV.ADO.NET.DB.FW.
7.2 Porovnání s SQL Clientem
Na přiložených dvou obrázcích (Obrázek 11, Obrázek 12) můžete pozorovat hlavní rozdíly mezi SQL Clientem a LabVIEW ADO.NET Database Frameworkem. Hlavní
LabView ADO.NET Database Framework Database
DataAdapter Builder
Presentation Builder
Assembly Builder
AssemblyInfo Builder DataSet
Builder
.assemblyInfo.cs .presentation.cs
.adapters.cs .cs
Database Mapper SQLDataSource DBMapper
<database>.dll
Obrázek 9 - LabVIEW ADO.NET Database Framework - Princip funkcionality
26 změna nastala v přesunutí těžiště databázového klienta z programovacího jazyku LV do .NET assembly. Důvodem je omezení LabVIEW .NET Connectivity Toolkitu (viz 2.1.1) nebo složitá konverze objektů (.NET objekt => LV Variant => CTS (viz 4.2)).
Obrázek 10 - SQL Client - Konverze objektů
Konverze objektů zapříčinila velký nárůst výpočetní náročnosti SQL Clineta.
Výpočetní náročnosti se budeme věnovat v kapitole nazvané „Testy rychlosti" (viz kapitola 7.8). Dalším omezením SQL Clienta, jehož přesnou příčinu se nám nepodařilo odhalit, je omezení maximálního počtu záznamů na hodnotu přibližně 150 000.
Domníváme se, že omezení je způsobeno nadměrným využitím RAM, které se u tohoto počtu záznamu pohybovalo kolem hodnoty 900MB.
Obrázek 11 - SQL Client - Schéma
Obrázek 12 - LabVIEW ADO.NET Database Framework - Schéma
Database ADO.NET LabVIEW
ADO.NET Providers
ADO.NET DataSet
Data Manipulation
Database
INFORMATION SCHEMA
ADO.NET
Database Mapper
TableAdapters
Strongly Typed DataSet
Presentation Layer
LabVIEW
Application
27
7.3 Database Mapper layer
Vrstva s názvem Database Mapper layer slouží k mapování databázového schématu na SQL serveru a jednotlivých instancí SQL serveru na dostupné síti. Vrstva poskytuje základní informace o databázovém schématu, které slouží pro další vytváření celého Frameworku. Princip mapování spočívá ve využívání systémových tabulek Microsoft SQL Serveru (viz kapitola 5.1). Třída SqlConnection obsahuje metodu GetSchema, pro získávání základních tabulek (metadat). Parametr metody GetSchema je název metadatové tabulky. Metodu nelze použít pro mapování relací, protože nezahrnuje všechny tabulky. Třída SqlDataAdapter obsahuje metodu FillSchema pro získání schématu tabulky - vlastností sloupců.
7.3.1 Struktura tříd a metod
Na následujícím obrázku (Obrázek 13) můžete vidět strukturu tříd vrstvy Database Mapper.
Obrázek 13 - Database Mapper - Struktura třid
Da taba se Mapper
DB Mapper
getTables()
getTablesList()
getTableSchema()
getColumns()
getDatabaseRelations()
getViews()
getDataSet(List<string>
tables)
SQLDataSource
getInstances()
getInstancesToList()
getDatabases()
getDatabasesToList()
28 7.3.2 Mapování databázových relací
Mapování databázových relací vykonává metoda getDatabaseRelations() třídy DBMapper (viz Obrázek 13). Princip tohoto mapování opět spočívá ve využívání systémových tabulek (viz kapitola 5.1) na SQL Serveru, ve kterých jsou definovány jednotlivé relace databázového schématu. Pro zmapování relace, tedy názvu tabulky a sloupce pro mateřskou a dceřinou tabulku, jsou zapotřebí tyto systémové tabulky z kolekce INFORMATION_SCHEMA:
KEY_COLUMN_USAGE
REFERENTIAL_CONSTRAINTS TABLE_CONSTRAINTS
Ve Frameworku jsou získávány relace pomocí konjunkce těchto tří systémových tabulek. Výsledné vytvoření třídy relace pro DataSet pak může vypadat třeba takto:
System.Data.DataRelation relation = new DataRelation(
dtTableConstr.Rows[i]["CONSTRAINT_NAME"].ToString(),
this.dataSet.Tables[tableNameParent].Columns[columnNameParent],
this.dataSet.Tables[tableNameChild].Columns[columnNameChild], false);
7.4 DataSet layer
Velmi důležitá vrstva DataSet layer generuje vzdálený model databázového schématu. Zdrojem pro generování vrstvy se stává instance třídy System.Data.DataSet, která obsahuje parametry databázového schématu získané z vrstvy Database Mapper layer (viz kapitola 7.3). Cílovým souborem je CS soubor, který generuje komponenta Tabulka 1 - ADO vs. ADO.NET
CodeDOM. Pro získání bohatého objektového modelu DataSetu je používána třída:
System.Data.Design.TypedDataSetGenerator.
Zmíněný generátor vytváří objektový model typu CodeDOM pro třídu DataSet s funkcionalitou, které se budeme věnovat v následující kapitole: 7.4.1.
Do vrstvy DataSet jsme implementovali i variantu vytvoření typovaného modelu DataSetu v XSD schématu a následného exportování do CS souboru pomocí příkazové řádky (CMD). Primárním účelem využití této implementace je oblast testování. Nelze tento princip využít pro generování celého Frameworku z důvodů omezení, kterým jsme se věnovali v kapitole: 3.4.1 v sekci XML Serializace. Dokonce ani nedoporučujeme
29 tuto variantu pro generování CS souboru, kvůli jeho nevelké podpoře návratových chyb z CMD.
7.4.1 Vygenerovaná struktura zajímavých typovaných tříd, vlastností a metod Obrázek 14 představuje zajímavé typované třídy, vlastnosti a metody, kterými se může pochlubit typovaný DataSet (viz kapitola 3.1.1). Na místě ostrých závorek jsou uvedeny názvy, které identifikují prvek databázového schématu (například: název tabulky nebo sloupce). Naznačená struktura je samozřejmě vygenerována pro všechny prvky databázového schématu – tedy pro všechny tabulky, sloupce a relace. Mezi zajímavé funkce můžeme zařadit například funkci třídy System.Data.DataTable nazvanou FindBy<název_id_sloupce>(int id_sloupec), která vyhledá záznam podle zadané hodnoty id v příslušné tabulce.
Obrázek 14 – Struktura tříd, metod a vlastností typovaného DataSetu
<dat aba se > Dat aS et
<table>DataTable
<table>Row()
Add<table>Row()
FindBy<ID_sloupec>()
New<table>Row()
Remove<table>Row()
<column>Column
<table>Row
<table>Row
<table>Row()
Is<FK_column>Null()
Set<FK_column>Null()
Get<child_tb>Rows()
<column>
relationFK_
<table1>_<table2>
30
7.5 TableAdapters layer
Obdobně jako má za úkol TableAdapter synchronizování vzdáleného pohledu, tak vrstva TableAdapters má za úkol synchronizování celého vzdáleného modelu databáze.
Vrstva vytváří sadu TableAdapterů (viz kapitola 3.1.2) typovaných pro každý jednotlivý pohled. Oproti běžnému TableAdapteru je funkcionalita rozšířena pomocí wrapperu o parametry konstruktoru (viz kapitola 7.5.1) nebo o parametry metody Update (viz kapitola 7.5.2). Generování vrstvy je založeno opět na komponentě CodeDOM. Variace SQL dotazů UPDATE, INSERT, DELETE jsou vytvářeny z výchozího SELECT dotazu třídou SqlCommandBuilder, o které jsme se zmínili v odstavci č.: 3.1.4. Součásti wrapperu třídy TableAdapter je connectionString. Uživateli je dána možnost vložit connectionString přímo do aplikace nebo jej může sestavit vyhledáním serverů, databáze a nastavením přihlašovacích údajů (Obrázek 15) v programu Frameworku.
Pro sestavování je využívána třída SqlConnectionStringBuilder.
Obrázek 15 - LabVIEW ADO.NET Database Framework - Connection to MS SQL Server
7.5.1 Parametry konstruktorů TableAdapter
Pro snadnou použitelnost a větší pole působnosti byl TableAdapter rozšířen o další dva parametry konstruktoru. První z nich dovoluje omezit příkaz SELECT klauzulí WHERE, jako jsme tomu byli zvyklí u dotazovacího jazyku SQL. Druhý parametr dovoluje změnit výchozí definici reference na třídu SqlConnection [14].
vygenerovanou Frameworkem a řídit tak celé připojení k databázi nezávisle na Frameworku. Třída SqlConnection zajišťuje připojení k SQL databázi. S využitím třídy SqlConnection můžete nastavit jiný connectionString aniž byste byli nuceni opětovně vygenerovat celý Framework. V případě rozdílných zdrojů databáze (serverů) je nutné zajistit integritu databázových schémat (původního a nově připojeného).
Příklady konstruktorů v jazyce C# a použití v LabVIEW:
using System.Data.SqlClient;
tabulkaAdapter(databaseDataSet.tabulkaDataTable dataTable);
31
Obrázek 16 - tabulkaAdapter(dataTable)
tabulkaAdapter(databaseDataSet.tabulkaDataTable dataTable, string where);
Obrázek 17 - tabulkaAdapter(dataTable, where)
tabulkaAdapter(databaseDataSet.tabulkaDataTable dataTable, SqlConnection connection);
Obrázek 18 - tabulkaAdapter(datatable, connetion)
tabulkaAdapter(databaseDataSet.tabulkaDataTable dataTable, SqlConnection connection,
string where);
Obrázek 19 - tabulkaAdapter(dataTable, connection, where)
7.5.2 Parametry metody Update()
Framework generuje přetíženou metodu Update pro třídu TableAdapter, neboli tabulkaAdapter (více o rozdílech mezi SqlDataAdapter a TableAdapter: 3.1.2), která programátorovi dovoluje aktualizovat provedené změny v tabulce DataTable [14].
První varianta metody Update je bez parametru. Druhá varianta aktualizuje záznamy, které byly předané jako reference na pole třidy DataRow[]. Poslední varianta dovoluje uživateli zobrazit dotaz a nechat uživatele rozhodnout, zda chce změny opravdu provést. Hláška je generována pomocí programátorům jazyka C# dobře známe třídy MessageBox z namespace System.Windows.Forms.
Na následujících třech obrázcích můžete vidět jednotlivé varianty metody Update třídy TableAdapter, konkrétně tedy tabulky s názvem „tabulka“.
32 tabulkaAdapter.Update()
Obrázek 20 - tabulkaAdapter.Update()
tabulkaAdapter.Update(DataRow[] datarows)
Obrázek 21 - tabulkaAdapter.Update(DataRow[] datarows)
tabulkaAdapter.Update(string message, string caption)
Obrázek 22 - tabulkaAdapter.Update(string message, string caption)
Na dalším obrázku (Obrázek 5) můžete vidět výslednou hlášku, která bude zobrazena uživatelovi. Hlášku je samozřejmě možné měnit pomocí parametrů message a caption.
Obrázek 23 - tabulkaAdapter.Update(string message, string caption) - Dotaz
7.6 Presentation layer
Vrstva byla navržena s cílem zjednodušit programátorovi v LabVIEW práci a předat mu data ve vhodné podobě pro další zpracování. Na základě požadavku vzniklého potřebami při zpracování technologický dat, od firmy Preciosa a.s., byla do této vrstvy zařazena funkcionalita nazvaná „ColumnToField“ (viz kapitola 7.6.1). Do budoucnosti je plánováno s dalším rozšiřováním této vrstvy podle potřeb programátorů v prostředí jazyka LabVIEW. Dále bylo v této vrstvě pamatováno na zpětnou kompatibilitu se současným řešením databázového klienta navrženého firmou Preciosa a.s. Proto vrstva „Presentation“ podporuje oddělené využití s SQL Clientem (více o SQL Clientu v kapitole: 6.1 SQL Client). V tomto případě je nutné zaručit, aby na vstup této vrstvy byla přivedena data (konkrétně reference na třídu System.Data.DataTable) s odpovídající vnitřní strukturou sloupců.
33 7.6.1 ColumnToField
Význam této funkcionality je především v odvětví zpracování technologických dat, které vyplývá z využití programovacího jazyka LabVIEW. Jedná se především o případy, kdy potřebujeme pracovat s celým sloupcem (polem) hodnot např.: při zápisu do prvku LV Graph. O tuto funkcionalitu požádala firma Preciosa a.s.
ColumnToField je funkcionalita, která převádí pole řádků System.Data.DataRow[] z hodnot typu object na jednorozměrné pole základního datového typu jako je například: System.Int32 nebo System.String. Programátorovi v LabVIEW se tak dostává výsledného zjednodušení v práci s celým sloupcem. Při používání této funkcionality se očekává, že programátor zajistí integritu dat a velikost pole. Tento postup bychom si samozřejmě nemohli dovolit například v oboru účetnictví, ale jak jsme se již zmínili v první kapitole o LabVIEW, hlavní pole působnosti LV je práce se signálem a obdobně technologickými daty. Framework samozřejmě podporuje i inverzní funkcionalitu, a to zpětné převedení a uložení pole do pole řádků, tedy kolekce tabulky DataTable [14].
Tento zpětný převod není prováděn na základě porovnávání id záznamů, protože jejich svázání s hodnotami by znamenalo opětné znesnadnění pro LV programátora. Stejné funkcionality jste si samozřejmě mohli všimnout i u SQL Clienta pod názvem Data Manipulation (viz kapitola 6.1.1). Obrázek 5 je ukázkou LV kódu s využitím ColumnToField z popisovaného Frameworku.
Obrázek 24 - Funkcionalita ColumnToField
7.7 Assembly layer
Assembly layer je velmi významná vrstva, která zajišťuje sestavení všech zmíněných vrstev Frameworku (tedy CS souborů) do jednoho výsledného DLL assembly se všemi potřebnými knihovnami. Vrstvu Assembly layer jsme implementovali ve dvou variantách:
34 S generováním pomocí komponenty CodeDOM
S využitím csc.exe kompilátoru a příkazového řádku CMD
Druhá varianta byla vytvořena pouze pro demonstrativní účely. Podrobněji se těmto variantám budeme věnovat v kapitolách: 7.7.1 a 7.7.2.
7.7.1 CodeDOM
Přiložená ukázka kódu prezentuje princip generování DLL assembly s využitím CodeDOM.
CSharpCodeProvider codeProvider;
CompilerParameters compilerParams;
CompilerResults res;
//Vytvoreni a nastaveni parametru compilatoru codeProvider = new CSharpCodeProvider();
compilerParams = new CompilerParameters();
compilerParams.ReferencedAssemblies.Add("System.dll");
compilerParams.ReferencedAssemblies.Add("System.Data.dll");
compilerParams.ReferencedAssemblies.Add("System.Xml.dll");
compilerParams.ReferencedAssemblies.Add("System.Windows.Forms.dll");
compilerParams.CompilerOptions = "/t:library";
compilerParams.GenerateExecutable = false;
compilerParams.GenerateInMemory = false;
compilerParams.OutputAssembly = assemblyPath + assemblyName + ".dll";
//Zkompilovani Assembly, v promene sourceCS je pole nazvu CS souboru res = codeProvider.CompileAssemblyFromFile(compilerParams, sourceCS);
7.7.2 Command-line interface (CMD)
Nevýhody této varianty jsme popsali ve vrstvě DataSet layer (viz kapitola 7.4).
Následující ukázka kódu demonstruje generování DLL assembly pomocí příkazového řádku a kompilátoru csc.exe.
c:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe /target:library /out:nazev_databaze.dll databazeDataSet.cs databazeDataSet.adapters.cs databazeDataSet.assemblyInfo.cs databazeDataSet.presentation.cs
7.7.3 Generování assembly v AppDomain
Následující ukázka kódu z našeho Frameworku demonstruje využití aplikační domény v případě opětovného generování assembly s jeho různými verzemi (viz kapitola 4.3.1 Assembly Versioning).
AppDomain assemblyDomain;
AssemblyBuilder assemblyBuilder;
35 //Vytvoreni applikacni domeny z CurrentDomain s nazvem assemblyDomain assemblyDomain = AppDomain.CreateDomain("assemblyDomain");
//Vytvoreni instance tridy AssemblyBuilder assemblyBuilder
=(AssemblyBuilder)assemblyDomain.CreateInstanceAndUnwrap(
typeof(AssemblyBuilder).Assembly.FullName, typeof(AssemblyBuilder).FullName);
//Zavolani metody ve ktere se vytvori dll errAssemblyCompile = assemblyBuilder.CStoDLL(
CSfiles.ToArray(), outputPath,
connStringBuilder.InitialCatalog);
//Unlodovani vytvorene Applikacni domeny AppDomain.Unload(assemblyDomain);
7.8 Testy rychlosti
Do testu jsme zahrnuli řešení Preciosy a.s., tedy SQL Client a naše řešení LabVIEW ADO.NET Database Framework. Nejprve jsme testovali celková řešení databázových klientů a poté pouze samotnou funkcionalitu „ColumnToField“(viz: 7.6.1).
Pro funkcionalitu „ColumnToField“ jsme následně optimalizovali kód a testovali výsledné rozdíly.
7.8.1 Jak jsme testovali
Pro potřeby testu jsme vygenerovali pomocí programovacího jazyku C#
databázovou tabulku s šesti sloupci, kde každý jednotlivý sloupec představoval jeden z nejběžnějších používaných datových typů. První sloupec obsahoval identifikační číslo záznamu, druhý byl typu System.Int32 pro který jsme generovali záznamy s náhodným číslem v rozmezí -100000 až 100000. Třetí sloupec byl naplněn reálnými čísly datového typu System.Double v rozmezí -1000 a 1000, čtvrtý sloupec datovým typem System.String, který reprezentoval náhodný textový řetězec o délce 4 až 10 znaků, pátý sloupec datovým typem System.DateTime s náhodným datem mezi lety 2008 až 2012 a poslední sloupec byl datového typu System.Boolean a obsahoval náhodnou hodnotu buď true nebo false.
Testovali jsme načítání celého sloupce do pole odpovídajícího datové typu pomocí funkcionality „ColumnToField“.
7.8.2 HW a SW podmínky testů
Testy byly provedeny v těchto hardwarových a softwarových podmínkách:
36 Microsoft SQL Server 2005 Express
Microsoft .NET Framework 3.5
Common Language Runtime v2.0.50727 Microsoft Visual Studio 2008
National Instruments LabVIEW 2011 CPU: Intel i5-2500K @4 x 3,3GHz RAM: Kingston 8GB DDR3 1333MHz SSD: Vertex 3 60GB 535/480 MB/s 7.8.3 Porovnání databázových klientů
V této kapitole budeme porovnávat celková řešení databázových klientů a námi vytvořený Frameworkem spuštěný přímo v CLR v2.0.50727 (viz kapitola 4), nikoliv volaný přes prostředí LabVIEW.
Počet
Preciosa SQL Client LabVIEW ADO.NET DB FW CLR v2.0.50727
Řádků Sloupců Default Optim. Cell
0
6
606 840 934 1
1 678 938 991 1
10 720 953 951 54
100 1022 1005 997 55
1000 3685 1008 1004 64
10000 32193 1077 1049 114
100000 940471 1833 1677 723
Tabulka 2 - Porovnání rychlostí databázových klientů [ms]
Figure 1 - Porovnání rychlostí databázových klientů [s]
0,001 0,01 0,1 1 10 100 1000
0 1 10 100 1000 10000 100000
Čas [sekundy]
Počet řádků
Preciosa SQL Client LabVIEW ADO.NET DB FW CLR v2.0.50727
37 7.8.4 Porovnání funkcionality ColumnToField
V grafu můžete porovnat rychlostní rozdíly mezi provedením funkcionality ColumnToField u databázových klientů. Zařadili jsme sem i zmíněnou optimalizaci kódu našeho Frameworku.
Počet Preciosa SQL Client Presentation Layer Řádků Sloupců Data manipulation Default Optim. Cell
0
6
6 4 4
1 14 6 5
10 42 5 5
100 322 6 6
1000 2998 9 7
10000 31012 36 21
100000 948116 347 197
Tabulka 3 - Porovnání rychlostí ColumnToField [ms]
Figure 2 - Porovnání rychlostí ColumnToField [s]
7.8.5 Zhodnocení výsledků
Z testů jasně vyplývá, že bylo dosaženo výrazného zrychlení u většího množství záznamu. U funkcionality ColumnToField s množství záznamů 10^5 jsme dosáhli zrychlení více jak 4800x. Pro celé řešení databázového klienta zrychlení dosahovalo hodnoty více jak 1300x. V obou případech řešení firmy Preciosa, SQL Client, dosahovalo času kolem 15,6 minut, kdežto řešení LabVIEW ADO.NET Database Framework se v obou případech pohybovalo okolo 1 sekundy. Zajímavého zlepšení
0,001 0,01 0,1 1 10 100 1000
0 1 10 100 1000 10000 100000
Čas [sekundy]
Počet řádků
Data manipulation Presentation Layer Prezentation Layer (Optimalizovaná)
38 jsme dosáhli i pomocí optimalizace Frameworku, které můžete pozorovat především na funkcionalitě ColumnToField.
7.9 Přidání Frameworku ve formě DLL do LV projektu
Následující postup popisuje přidání Frameworku, vygenerované DLL knihovny do LV projektu.
1) Nejprve vybereme konstruktor v paletě .NET Connectivity (Obrázek 25) a přesuneme ho do vývojového diagramu.
Obrázek 25 - LabVIEW .NET Connectivity Tookit
2) Vybereme cestu k vygenerovanému DLL (Obrázek 26) pomocí tlačítka
„Browse“
39
Obrázek 26 - Select .NET Constructor
3) Po vybrání cesty k DLL vybereme požadovaný objekt a konstruktor a potvrdíme tlačítkem OK
4) Výsledný konstruktor, v blokovém diagramu, může vypadat třeba takto:
Obrázek 27 - .NET Constructor - example
7.10 Příklady použití Frameworku
V této kapitole jsme uvedli několik zajímavých příkladů použití námi vytvořeného Frameworku. Předem se omlouváme za velmi „zhuštěný kód“ v důsledku nedostatku místa.
40 7.10.1 Vyhledání prvku v tabulce podle ID
Obrázek 28 - Vyhledáni prvku podle ID
7.10.2 Vytvoření nového záznamu v tabulce a vrácení přiřazeného ID
Obrázek 29 - AddRow and getID
41
8 Závěr
V současné době je možno k produktu LabVIEW dokoupit databázového klienta pod obchodním názvem LabVIEW Database Connectivity Toolkit (dále toolkit) od firmy National Istruments. Funkcionalita tohoto toolkitu byla pro firmu Preciosa a.s.
nedostatečná a proto navrhla vlastního databázového klienta nazvaného SQL Client, kterým se pokusila odstranit hlavní nedostatky toolkitu a využít vlastnosti novější technologii ADO.NET. Toolkit firmy National Instruments přistupuje k databázovému uložišti pomocí technologie zvané ActiveX Data Objects (ADO). Oproti této technologii ADO.NET nabízí větší komfort při práci s daty ve formě tzv. vzdálených pohledů (aplikační dočasné uložiště dat), robustnější podpory XML a mnoho dalších výhod.
Zmíněný SQL Client se na rozdíl od toolkitu potýká s výpočetní a paměťovou náročností způsobenou složitými konverzemi .NET objektů a LV datových typů a také nenabízí komfort, na který jsou zvyklý programátoři Entity Frameworku. Tato skutečnost nás dovedla k navrhnutí vlastního databázového klienta, který by využíval výhody ADO.NETu, případně novější zmíněné verze ADO.NET Entity Framework, a odstranil tak nedostatky SQL Clienta a LabVIEW Database Connectivity Toolkitu.
Navržené řešení jsme koncipovali s požadavkem na kompatibilitu se současným SQL Clientem.
Jazyk LabVIEW obsahuje podporu Microsoft .NET Frameworku, ale s jistými omezeními, která nám neumožnila implementovat zmíněnou vyšší verzi ADO.NETu zvanou Entity Framework. Konkrétně se jedná o nedostatečnou podporu Microsoft .NET Frameworku 4.0 [16] a generických tříd [17]. Proto pokročilé objektově-relační mapování zůstává nadále otázkou budoucí implementace.
Výpočetní náročnost a omezení SQL Clienta nás vedla k přesunutí těžiště databázového klienta mimo prostředí LabVIEW a vytvoření sady objektů, kterou jsme nazvali LabVIEW ADO.NET Database Framework. Tento Framework nabízí plnohodnotného databázového klienta využívajícího komponentu ADO.NET. Pomocí vygenerovaného DLL assembly Framework umožňuje implementaci databázového klienta do LabVIEW. Dále supluje (napodobuje) programátorský komfort, na který jsou zvyklí programátoři používající Entity Framework. Mimo to dosahuje výrazného
42 zrychlení oproti SQL Clientu v některých případech více jak 4800 krát. Framework také přináší typovou bezpečnost a kontrolu relačních a integritních omezení na aplikační úrovni. V LabVIEW jsme dosáhli zjednodušení návrhu databázové vrstvy pomocí sktruktury tříd odpovídající databázovému modelu.
8.1 Možnosti rozšíření
Vytvoření wrapperu pro komponentu CodeDOM
Rozšíření o další cílová uložiště jako jsou: Oracle, DB2 a MySQL,
Možnost definování výchozí hodnoty pro DBNull u funkce ColumnToField Možnost vybrání tabulek a sloupců pro vytváření DLL assembly
Rozšíření kompatibility propojení s řešením SQL Client Rozšíření funkcionality Presentation Layer
Podpora jednoduchých i složených jednosměrných SQL dotazů Implementování funkcionality DataGridView
Implementace Frameworku jako nástroje LabVIEW V případě podpory LV implementace Entity Frameworku
