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

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

In onderstaande afbeelding vind je 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 deze 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 is 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.

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

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. zijn delen weggehaald omdat zij aan het voorbeeld niets toevoegen. Dit wordt weergegeven met … .

create function dla_method2sql (

   @method_id Int

  )

returns varchar(8000)

as

begin

...

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 declaratie vraagt de cursor om de naam en het type van een property. Deze worden stap voor stap bewerkt.

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

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 colnames wordt een lijst van kolomnamen opgenomen; in 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.

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

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.

Er was echter 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 de SQL Server trigger. In het voorbeeld wordt getoond hoe op basis van de wijziging in een property tabel een alter table script gemaakt wordt.

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

Op het moment dat een property aangepast wordt, 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 wijzigingsstatements 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 modelverificatie en het 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. Er kan echter 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 het 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 opgeslagen die de toestand van een of meer objecten weergeven, en gegevensbewerkende services die de toestand van bedrijfsobjecten aanpassen.

In het voorbeeld wordt getoond hoe op basis van de wijziging in een property tabel een alter table script gemaakt wordt.

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 is een groot aantal methoden opgenomen waarmee de presentatie (de GUI in VO) communiceert. Wederom een aantal code snippets ter verduidelijking van de opzet.

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

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 het 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 gegevensverwerkende service. De opzet is niet veel anders dan de gegevensverstrekkende service, zoals de code laat zien

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

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 dat 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 dat 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 wijze de implementatie veranderd kan worden zonder dat het interface verandert, bijvoorbeeld wanneer de library 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.

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 })

...

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.