Een Data Driven toepassing op basis van Visual Objects en SQL Server

Een Data Driven toepassing op basis van Visual Objects en SQL Server


Door Bert Dingemans DLA Ontwerp & Software www.dla-architect.nl

DLA Ontwerp & Software


Inleiding In voorgaande artikelen heb ik een aantal onderwerpen belicht die ten grondslag liggen aan dit artikel. Lange tijd geleden heb ik een serie artikelen geschreven over data driven programmeer technieken. Daarnaast heb ik een artikel geschreven over het werken met een CASE tool binnen Visual Objects projecten. In dit artikel komen deze twee onderwerpen bij elkaar. In de afgelopen tijd ben ik de repository van een CASE tool gaan gebruiken als data dictionary voor een administratieve toepassing. De voorbeelden in dit artikel zijn gebaseerd op SQL-Server 2000 en Visual Objects 2.6 met VO2ADO.

Data model Repository De CASE tool die gebruikt is, de DLA-architect, heeft een repository bestaande uit een relationele database in MS-Access of SQL server. In deze repository worden alle onderdelen van een ontwikkeltraject vastgelegd. Naast de diagrammen bevat de repository de definities van alle entiteiten. DLA staat voor Drie Lagen Architectuur. De drie lagen die onderkend worden zijn • Presentatielaag • Gebruikerslaag • Bedrijfsdomeinlaag In onderstaande tabel worden de belangrijkste entiteiten kort beschreven Entiteit Processtap

Laag Presentatielaag

Interactie

Presentatielaag

Gegevensbewerkende en Presentatie/gebruikerslaag –verstrekkende services

Gebeurtenissen

Gebruikerslaag

Object typen

Bedrijfsdomeinlaag

Omschrijving Een toepassing bestaat uit een aantal processen welke weer uit procestappen bestaat. Een proces en haar stappen kan in een applicatie geïmplementeerd worden als een menu of een wizard. Een interactie is één of meerdere menscomputer interacties bestaande uit bijvoorbeeld een rapportage of een invoer/bewerk scherm Dit zijn entiteiten die ervoor zorgen dat een interactie kan communiceren met de gegevens in de onderliggende entiteiten. Zo zal een gegevensverstrekkende service er bij een invoerscherm voor zorgen dat de besturingselementen gevuld worden met gegevens van de objecten. De gegevensbewerkende services zorgen ervoor dat de toestand van objecten gewijzigd worden. Gebeurtenissen beschrijven functionele “gebeurtenissen” die plaatsvinden binnen het domein van de toepassing. Gebeurtenissen zijn de koppeling tussen object-typen en gegevensbewerkende services. Zij zorgen voor de inkapseling van de structuur van het bedrijfsdomein Dit zijn de bedrijfsobjecten met bijbehorende methoden en attributen. Attributen houden de toestand van een object vast. Methoden wijzigen de toestand DLA Ontwerp & Software


object vast. Methoden wijzigen de toestand van de attributen na aanroep van een gebeurtenis. In onderstaande afbeelding een grafische voorstelling van de bovengenoemde entiteiten. Dit is niet het complete datamodel, detailentiteiten en -relaties zijn niet opgenomen om de leesbaarheid te behouden.

Deze structuur is geïmplementeerd in een SQL server omgeving en bevat de gegevens van het objectmodel. Het voorbeeld dat gebruikt wordt is een eenvoudige hoteladministratie voor reserveringen. In de voorbeeldtoepassing zijn alle entiteiten uitgewerkt. Echter in dit artikel zullen we in detail ingaan op de services en de methoden. Dit omdat dezer vanuit technisch oogpunt het meest interessant zijn.

Implementatie SQL server Binnen SQL server zijn de data dictionary objecten gedefinieerd als tabellen met een aantal constraints, zoals primary en foreign keys. De tabelstructuur wordt benaderd vanuit de CASE tool en deze zorgt ervoor dat er rijen worden bewerkt in de tabellen. Door gebruik te maken van de constraints mogelijkheden van SQL server is het mogelijk om een deel van de object model consistentie te implementeren op basis van relationele constraints.



De repository is nu beschikbaar voor de CASE tool. Daarnaast is het nu mogelijk om de gegevens in de repository te gebruiken voor andere zaken. Bijvoorbeeld voor een Visual Objects windows client. SQL server biedt naast de opslag van gegevens veel andere functionaliteiten zoals stored procedures, stored functions en triggers. Deze functionaliteit kan gebruikt worden om de structuur van de repository te vertalen naar voor de VO client leesbare SQL statements. Hiertoe zijn een aantal stored procedures en functions geschreven. Het gaat te ver om deze allemaal in detail te behandelen in dit artikel. Hier wordt één stored function beschreven. De andere procedures en functions doen soortgelijke bewerkingen op de tabellen. Stored procedures en stored functions zijn beschikbaar in de grotere relationele database zoals oracle, sybase en sql server. Met deze stored procedures en stored functions is het mogelijk om te programmeren in een relationele database. Voordeel van deze werkwijze is natuurlijk het single point of maintenance. Een ander voordeel is dat de performance van stored procedures vaak iets beter is. De database maakt van een stored procedure een execution plan en op basis daarvan wordt de stored procedure gecompileerd. Stored procedures en functions bieden daarnaast een eenvoudiger structuur voor beveiliging en autorisatie. Verschil tussen een stored procedure en een function is dat de function een return waarde heeft en daardoor de mogelijkheid heeft om in een select statement te worden opgenomen.

In dit voorbeeld wordt een methode object (zoals dit is opgeslagen in de database) vertaald naar een update, insert of delete statement. Het wordt gedaan op basis van een stored function. In het voorbeeld zijn delen weggehaald omdat zij aan het voorbeeld niets toevoegen. Dit wordt weergegeven met … . #L# create function dla_method2sql ( @method_id Int ) returns varchar(8000) as begin … #L# Met bovenstaande programma code wordt een stored function aangemaakt in de database. Zoals je ziet kunnen er parameters weergegeven worden en is er een resultwaarde te definieren. Helaas is het momenteel niet mogelijk om een resultwaarde van het type text te gebruiken. Voor heel grote statements kan 8000 karakters te weinig zijn. Gaat dit gelden dan zal met temporary tables gewerkt moeten worden. In de onderstaande programma code wordt een cursor gedeclareerd. Een cursor is een variabele in een relationele database die niet gebaseerd is op een resultset, maar die rij voor rij door een resultset heen stapt en op basis van deze stappen een bewerking doet, bijvoorbeeld het samenvoegen van strings. In de cursor vraagt de cursor om de naam en het type van een property. Deze worden stap voor stap bewerkt. #L# DECLARE Parameter_Cursor CURSOR FOR SELECT PROPERTY.property_name , Rtrim(PROPERTY.type_content) FROM PROPERTY , METHOD_PARAMETER WHERE PROPERTY.property_id=METHOD_PARAMETER.property_id AND METHOD_PARAMETER.method_id = @method_id



#L# In de onderstaande programma code worden de properties vertaald naar een insert statement. Update en delete zijn weggelaten. Dit wordt gedaan door de cursor te vertalen naar twee string variabelen die opgebouwd worden op basis van property namen en hun typen. Typen zijn nodig om bijvoorbeeld string scheidingstekens op te nemen. In de colnames wordt een lijst van kolomnamen opgenomen in de varnames wordt een verwijzing naar de kolomnaam opgenomen. De VO client gaat deze in een later stadium vervangen door de inhoud van form controls met dezelfde naam. In de variabele strTemp wordt een raamwerk van een insert statement geplaatst. Na het verwerken van de cursor wordt dit raamwerk gevuld met de daadwerkelijke waarden van kolomnamen en kolomverwijzingen. Dit statement wordt als returnwaarde teruggegeven en kan dus met behulp van een select statement worden opgevraagd door de client. #L# OPEN Parameter_Cursor IF @method_type = 'Insert' BEGIN select @strTemp = 'INSERT INTO ' + @class_name + ' ( [COLNAMES] status ) VALUES ( [VALNAMES], ''[NEWSTATUS]'' ) ' END … SELECT @colnames = '' SELECT @valnames = '' FETCH NEXT FROM Parameter_Cursor INTO @property_name, @type_content WHILE @@FETCH_STATUS = 0 BEGIN IF @method_type = 'Insert' BEGIN IF @property_name <> @object_identifier … select @colnames = @colnames + @property_name … select @valnames = @valnames + ' ''#' + lower(@property_name) + '#'' ' END … delete en update statement FETCH NEXT FROM Parameter_Cursor INTO @property_name, @type_content END CLOSE Parameter_Cursor DEALLOCATE Parameter_Cursor IF @method_type = 'Insert' OR @method_type = 'Update' BEGIN SELECT @strTemp = Replace(@strTemp, '[COLNAMES]', @colnames + ', ') END … SELECT @strTemp = Replace(@strTemp, '[VALNAMES]', @valnames) … return @strTemp END --Procedure #L#



Met de stored procedures en functions is het nu mogelijk om de structuur van de data dictionary objecten die bewerkt worden met de CASE tool om te zetten naar sql statements die door de client worden geparametriseerd en uitgevoerd. Echter er was behoefte aan een extra functie welke bijvoorbeeld tijdens een iteratief ontwikkeltraject handig is. Dat is het bijwerken van de database tabelstructuur op basis van wijzigingen die gemaakt worden in de data dictionary tabellen. Hiervoor moest gebruik gemaakt worden van de derde extra functionaliteit in SQL server de trigger. In het voorbeeld wordt getoond hoe op basis van de wijziging in een property tabel een alter table script gemaakt wordt. #L# CREATE TRIGGER Property_Update ON PROPERTY FOR Update AS BEGIN INSERT INTO SqlStatement (StatementText) SELECT 'ALTER TABLE ' + CLASS.class_name + ' DROP COLUMN ' + deleted.property_name FROM CLASS , deleted WHERE deleted.class_id = CLASS.class_id INSERT INTO SqlStatement (StatementText) SELECT 'ALTER TABLE ' + CLASS.class_name + ' ADD ' + inserted.property_name + CASE inserted.type_content WHEN 'S' THEN ' Char(' + CAST(inserted.length AS Varchar(4)) + ') ' WHEN 'D' THEN ' DateTime ' … END + ' NULL ' AS Statement FROM CLASS , inserted WHERE inserted.class_id = CLASS.class_id END #L# Op het moment dat een property aangepast wordt dan wordt op basis van de trigger een tweetal statements opgebouwd om de tabelstructuur aan te passen. De eerste is dat de kolom die gewijzigd is wordt verwijderd uit de tabel op basis van een drop column statement vervolgens wordt er een add column gedaan. Deze worden weggeschreven naar een tabel in de database waarin alle wijzigingsstatement verzameld worden. Wordt de client opgestart dan kan gecontroleerd worden met behulp van een stored procedure of er wijzigingen in de wacht staan. Vervolgens worden deze wijzigingen doorgevoerd. De opzet van de alter table statements zou iets efficiënter kunnen. Zo wordt er altijd eerst een drop column en vervolgens een add column gedaan. Dat is niet altijd noodzakelijk. Daarnaast is het niet bij alle eigenschappen van een property noodzakelijk dat een alter table uitgevoerd moet worden. Met sql server is het mogelijk om tabelinhoud te transformeren naar allerhande structuren. In deze toepassing wordt de tabelinhoud vertaald naar sql statements die bijvoorbeeld de inhoud, maar ook de structuur van een database aanpassen. Voordeel van deze werkwijze is dat een deel van de werkzaamheden zoals het maken van sql statements geautomatiseerd kan plaatsvinden. Daarnaast is het vertalen van deze sql statements naar andere functies zoals het creëren van stored procedures en funcions op basis van de opgebouwde statements een relatief kleine stap. Een bijkomend voordeel is dat door het gebruik van een CASE tool model verificatie en wijzigen van het object model



gecontroleerd kan gebeuren. Vervolgens kunnen de gewijzigde tabelstructuur en de gewijzigde sql statements direct gebruikt worden door de client toepassing. Natuurlijk is het niet mogelijk om alle SQL statements te generen op basis van het object model in de repository. Er zijn altijd statements die zo complex zijn dat handmatige aanpassing nodig is. Denk bijvoorbeeld aan management rapportages. Echter er kan wel een template gegenereerd worden die als uitgangspunt kan dienen voor de aanpassing.

Implementatie Visual Objects Voor het werken met een drie lagen architectuur waren reeds in Visual Objects een aantal classes gedefinieerd die deze opzet implementeren. In eerste instantie op basis van DBServer met DBFCDX bestanden later op basis van de SQL classes van VO en nu met het beschikbaar komen van VO2ADO in 2.6 met deze add on. De implementatie bestaat zoals de naam al zegt uit een drietal lagen te weten: • Bedrijfsdomeinlaag (hierin zijn de bedrijfsobjecten gedefinieerd die de toestand van de objecten in werkveld van de applicatie vastleggen • Gebruikerslaag, de verschillende gebeurtenissen die vanuit de gezichtspunten van verschillende gebruikers te onderkennen zijn • Presentatielaag met services De services zijn de uiteindelijke interface tussen de GUI en de gebeurtenissen en bedrijfsobjecten. Hierbij worden gegevensverstrekkende services die de toestand van een of meer objecten weergeven en gegevensbewerkende services, welke de toestand van bedrijfsobjecten aanpassen. Deze drie lagen kunnen grotendeels geïmplementeerd worden in de database In de hier beschreven toepassing wordt dit gedaan tot aan de services. In de client applicatie is een service class gebouwd welke communiceert met de database. Deze service class geldt als een interface naar de GUI in de VO applicatie. Voordeel van deze werkwijze is dat de GUI eenvoudig vervangen kan worden door een andersoortige GUI (zoals ASP.Net), maar ook dat de onderliggende structuur aangepast kan worden. Zo is het mogelijk om de SQL statements in de lagen te vervangen voor SQL statements van een ander soort relationele database, maar ook door de sql statements tijdens het ontwikkelen op basis van stored functions te verwerken en later deze te vervangen door hard gecodeerde statements in een statische service class. Bijvoorbeeld uit security of performance overweging. In de service class zijn een groot aantal methoden opgenomen waarmee de presentatie (de GUI in VO) communiceert. Wederom een aantal code snippets ter verduidelijking van de opzet. #L# CLASS ServicesObject INHERIT ServiceLayer METHOD GetSupplyService(strName, aPara) CLASS ServicesObject LOCAL strStatement AS STRING strStatement := ProcessSQL(; "SELECT dbo.DLA_SERVICE2SQL( service_id ) AS statement FROM SERVICE WHERE service_name = '" + strName +"'", aPara) RETURN strStatement #L# Deze methode op het ServicesObject zorgt ervoor dat er een select statement wordt opgebouwd op basis van een name van een service in de data dictionary tabellen. Dit statement wordt vervolgens verwerkt met de methode processSQL. Deze zorgt ervoor dat het SQL statement geparametriseerd wordt met de parameters die via de array aPara aan het SQL statement worden gekoppeld. De methode processSQL bestaat voornamelijk uit een strtran() op het sql statement.



Een andere methode op het ServicesObject is het verwerken van een gegevensverstrekkende service. De opzet is niet veel anders dan de gegevensverstrekkende service. Zoals de code laat zien #L# METHOD ExecuteModifyService(strName, aParameterList) CLASS ServicesObject LOCAL STRId AS STRING STRId := SELF:ServiceName2Id(strName) IF SELF:ProcessPreStates(strId, aParameterList) SELF:ProcessModify(strId, aParameterList) ENDIF

METHOD ProcessModify(strService, aList) CLASS ServicesObject LOCAL strSql AS STRING LOCAL objSelect AS AbstractSqlSelect LOCAL strStatement AS STRING strSql := " EXEC DLA_MODIFY2SQL " + strService objSelect := AbstractSqlSelect{strSql, objCon } objSelect:Execute() DO WHILE !objSelect:eof strStatement := Array2Sql(objSelect:FIELDGET("method_sql"), aList) IF !ExecuteSql(strStatement) EXIT ENDIF objSelect:Skip(1) ENDDO #L# In de code is te zien dat op basis van de servicenaam er een id opgezocht wordt in de database en dit id wordt verder gebruikt voor het verwerken van de sql bewerkingsstatements die opgehaald worden op basis van de service id. Een ander aardig punt wat hier naar voren komt sluit aan op een discussie welke een tijd geleden op de newsgroup gevoerd werd. Dat betreft de class AbstractSQLSelect. Dit is een delegate pattern welke de communicatie met de gegevensbestanden verzorgt. Je ziet in deze class allerlei statements terugkomen die overeenkomen met het SQLSelect object van VO. Terwijl er binnen dit object toch echt met VO2ADO gewerkt wordt. Voordeel van deze opzet is dat later op eenvoudige de implementatie veranderd kan worden zonder dat de interface verandert. Bijvoorbeeld wanneer de libray VO2ADONET beschikbaar komt. De volgende stap is dat de GUI in de VO applicatie moet gaan communiceren met de services (zowel gegevensverstrekkend als bewerkend). Binnen de toepassing wordt gewerkt met een opzet van een treeview met daarnaast een invoer/bewerkscherm zoals in onderstaande afbeelding te zien is



Dit overview scherm met een combinatie van een treeview en een detailscherm is een onderdeel van de class library die gebruikt wordt binnen VO om te communiceren met relationele databases. De CASE tool genereert SQL statements en eventueel stukken VO programma code. Deze worden gecombineerd met de class library die zorg draagt voor de presentatielaag. De presentatielaag communiceert met de serviceslaag die de gegevensverstrekkende en bewerkende services aanbiedt aan de presentatielaag. De presentatielaag voor de standaard schermen doet niets anders dan aangeven welke services aangeroepen moeten worden voor een bepaalde actie. In onderstaande programmacode wordt aangegeven hoe dit is opgezet. #L# METHOD Init CLASS PresentationObject … AAdd(aIdentifiers, { "Application ", "Application_id" }) AAdd(aDetailServices, { "Application ", "Detail_Application " }) AAdd(aLookUpServices, { "Application ", "Lookup_Application " }) AAdd(aInsertServices, { "Application ", "Create_Application " }) AAdd(aUpdateServices, { "Application ", "Modify_Application " }) AAdd(aDeleteServices, { "Application ", "End_Application " }) AAdd(aCaptions, { "Application ", "Application " }) AAdd(aTreeChildren, { "Application ", {{ "Entity", "Lookup_Entity_Application" }}}) AAdd(aTreeImage, { "Application ", 1 }) … #L#



In de programmacode is te zien hoe voor ieder soort actie in de presentatielaag er een service gekoppeld wordt. Daarnaast worden de kind entiteiten gedefinieerd voor een node in de boom. Hierdoor wordt het mogelijk om de treeview in het scherm op eenvoudige wijze op te bouwen en de kinderen van een bepaalde entiteit te tonen wanneer dit door de gebruiker gewenst wordt. Het is dus mogelijk om op eenvoudige wijze een “oneindige” boom te definiëren als je er maar voor zorgt dat elke entiteit in het presentatieobject een aantal kinderen gedefinieerd heeft. Vanzelfsprekend schreeuwt dit presentatieobject om een data driven oplossing. De laatste stap die nodig is om de schermen uit bovenstaande afbeelding applicatiespecifiek te maken is het definieren van de eerste nodes in de treeview. Dat is mogelijk op basis van een methode aanroep op het treeview object. De rest van het gedrag is afkomstig uit de class library.

Tot slot In dit artikel is ingegaan op het werken met SQL server in combinatie met Visual Objects om een toepassing data driven te maken. SQL server is een krachtige database met de mogelijkheid om een groot deel van de business logica te definieren in de database. Door het gebruik van de combinatie van een CASE tool en een class library in Visual Objects is het mogelijk om snel toepassingen te ontwikkelen. Daarnaast is het door aanpassingen in zowel VO als SQL server goed mogelijk om aanpassingen aan te brengen in de toepassing, waarbij validatie van het object model zorgt voor een consistent bedrijfsobject model. Dit artikel laat slechts een klein deel van de toepassing zien. Mocht er interesse zijn in artikelen over bijvoorbeeld de opzet van de class library dan verneem ik dat graag. Bijvoorbeeld via de SDGN nieuwsgroep of direct via e-mail.

Over de auteur Bert Dingemans is een oude bekende van de SDGN, bijvoorbeeld als auteur en spreker. Bert heeft een voorliefde voor data-driven programmeren, CASE tools en object modellering. Hij is werkzaam bij Bureau Jeugdzorg Utrecht en werkt daarnaast als freelancer op het veld van CASE en OO. Meer informatie is te vinden op www.dla-architect.nl.


Een Data Driven toepassing op basis van Visual Objects en SQL Server

Recommend Documents