[.net/alg] In welke Layer de Null waarde afvangen?

[foske]

In iedere applicatie heb je eigenlijk wel te maken met null waardes. Zo ook in de nieuwe applicatie waar ik nu mee bezig ben. Nu komt het in deze applicatie veelvoudig voor dat met name data uit de database null kan zijn en ik zit met nogal een paar opties om dit op te lossen.

Nu heb ik een aantal mogelijkheden om de null waardes op te vangen:

- in de SQL. (isnull())
- direct bij het vullen van de attributen van mijn object (reader.isDbNull(i))
- bij het vullen van de UI

Dan is er nog de keuze, wat ga ik erin zetten. Ik kan het bijvoorbeeld wel in SQL doen, maar ga ik voor een string dan zeggen isnull(veld1, "") of "geen gegevens". Het laatste is natuurlijk niet netjes omdat de tekst dan hardcoded in mijn DAL zit. Hetzelfde geldt eigenlijk voor de 2 optie, bij het vullen van de attributen.

In dit opzicht blijft de UI dus over. Daar checken op de Null waarde, en dan de gewenste tekst neerzetten (in eventueel gewenste taal, mocht dit in de toekomst nodig zijn). Maar is dit zowiezo wel de beste plek? Wat daar nog bij komt, is dat deze applicatie ook deels beschikbaar komt als webservice, die de objecten doorschuift.

Dit zou dus betekenen dat klanten die de webservice willen gebruiken, zelf moeten checken op null waardes, terwijl ik het ze zo makkelijk mogelijk wil maken. En ze eigenlijk alleen maar de mogelijkheid wil geven om een soort template te bouwen, rondom onze webservice. Maar dit zou dan ook weer betekenen dat integers worden doorgestuurd als string, omdat "geen gegevens" de standaard waarde moet zijn.

Ikzelf neig toch het meest naar de laatste methode, maar ik vroeg mij af of er iemand was die mij op een andere gedachte kan brengen, of juist kunnen 'beamen' dat ik goed zit

[Verwijderd]

Zeker waar ik ook niet altijd raad mee weet. Effe dit topic in mijn bookmark gezet.

Tot nu toe heb ik vooral in VB.Net geprogrammeerd. Daarin heb je niet zoveel null-warden bij je attributen. Een string bleef dus gewoon leeg en een integer 0. Tegenwoordig met C# bezig.
Maar ik zou zeggen in je business layer, dus bij het vullen van het object.

Maarje, weer even goede argumenten om het niet te doen zeker? Ben benieuwd wat anderen hiervan dneken.

[D4Skunk]

Wat je kan doen, is een tussenlayer maken die je objecten omzet (=mvc)
Wanneer je mvc gebruikt, zou de omzetting van null -> een scherm-waarde in je controller gebeuren.
Je oorspronkelijke (business model) is dan je model, en je ui is je view; de transformatie tssn model en view gebeurt in je controller.

[djluc]

Misschien is het duidelijk om gewoon de waarde null of iets als undefined te gebruiken? Gewoon een standaard methode gebruiken, dat is het belangrijkste.

[dingstje]

Ik zou het zetten in de UI-laag. Moest ik gebruik moeten maken van een webservice en die stuurt mij een waarde 'Sorry, dit veld is leeg' o.i.d. zou ik er gek van worden. In mijn UI-laag bepaal ik op welke manier ik de user duidelijk maak dat er geen waarde is. Het is ook zo dat 'Sorry, dit is een leeg veld' veranderlijk is, en mogelijk afhankelijk van het soort data dat je opvraagt. Verder is null ook veel intuïtiever voor de developer imho.

[foske]

D4Skunk schreef op maandag 30 mei 2005 @ 18:42:
Wat je kan doen, is een tussenlayer maken die je objecten omzet (=mvc)
Wanneer je mvc gebruikt, zou de omzetting van null -> een scherm-waarde in je controller gebeuren.
Je oorspronkelijke (business model) is dan je model, en je ui is je view; de transformatie tssn model en view gebeurt in je controller.

MVC gaat dus een stukje verder. Dat is in de UI zetten, maar dan op een gescheiden manier. Het geluid wat ik dus hoor is, zet het in de UI.

@Dingstje:
Dat is inderdaad ook weer de gedachte die ik zelf ook een beetje had, ik kan het wel makkelijk proberen te maken voor 3e partij, maar misschien willen die het wel op hun eigen manier in beeld zetten.

@djluc:
Het gebruiken van de waarde "undefined" ben ik zelf niet zon fan van. Daar is namelijk Null al voor in het leven geroepen. Een speciale staat van een object waarin hij geen waarde heeft. Als je daar Undefined van maakt, heeft hij dus eigenlijk wel een waarde, maar die waarde stelt niets voor.

Even C#/.net specifiek, dit betekent wel bij het uitlezen van mijn reader in de velden waar null kan voorkomen, eerst de isDbNull methode moet uitvoeren. (Hoewel dit wel te samen te vatten moet zijn in een aparte methode).

[ Voor 12% gewijzigd door foske op 30-05-2005 19:30 ]

[whoami]

Veel hangt af van wat je precies in je DAL doet, en wat je precies in je GUI doet.

Voor mijn gevoel zou ik in 'm DAL m'n object gaan opvullen, en daar rekening houden met de null-values.

[foske]

@whoami:
Dit business object heeft attributen van het type string, int en date. Inprincipe willen we dat als er null waardes terug komen, dat er voor alle types komt te staan "geen gegevens".

Als je dit in DAL gaat doen, betekent dit dat je niet meer het type int of Date kan gebruiken. Nu is het zo dat er waarschijnlijk nooit gerekend gaat worden worden met deze waardes, maar is het niet netter om deze waardes pas om te zetten in een string zodra ze in bijvoorbeeld een label gestopt worden?

[ Voor 8% gewijzigd door foske op 30-05-2005 20:27 ]

[MaxxRide]

In principe is het afvangen van isnull richting DAL een taak van je business layer, deze heeft immers de intelligentie om te bepalen of de waarde gevuld moet zijn.

Het omzetten van een null value in een zinvolle waarde voor je presentatielaag is een twijfel geval.
1) Gebruik je presentatielaag, deze is immers verantwoordelijk voor het tonen van de waarden van een object.
2) Laat je BO het doen, deze weten het beste wat de bedoeling is met een waarde. Dus bijv. persoon.TelefoonnummerAsString (in een tekstbox) oid. (Deze functie is een vb. kan natuurlijk ook een overloaded fie zijn oid)


Nog even over MVC, volgens mij is dat toch als volgt:
Model = object(en) onder handen
View = een view op deze objecten (bijv een verzameling componenten, tekstfile etc)
Controller = een componen dat het Model "controlled" dus bijv. Auto.Rem(); wanneer er op de knop "remmen" wordt gedrukt, welke een onderdeel is van de controller.

[whoami]

Fossie schreef op maandag 30 mei 2005 @ 20:26:
@whoami:
Dit business object heeft attributen van het type string, int en date. Inprincipe willen we dat als er null waardes terug komen, dat er voor alle types komt te staan "geen gegevens".

Dat is dan een taak van de presentatie-laag.

[MaxxRide]

Als je dit in DAL gaat doen, betekent dit dat je niet meer het type int of Date kan gebruiken. Nu is het zo dat er waarschijnlijk nooit gerekend gaat worden worden met deze waardes, maar is het niet netter om deze waardes pas om te zetten in een string zodra ze in bijvoorbeeld een label gestopt worden?

Ik zou het zeker bij het elementaire formaat laten, doe je dat niet dan krijg je het var idee van javascript oftewel niet strong-typed of option explicit uit in VB. Zeker niet mijn voorkeur!

[MaxxRide]

whoami schreef op maandag 30 mei 2005 @ 20:28:
[...]

Dat is dan een taak van de presentatie-laag.

Of van je businesslayer die bepaald hoe de waarde er "als string" uit moet gaan zien

[whoami]

MaxxRide schreef op maandag 30 mei 2005 @ 20:29:
[...]


Of van je businesslayer die bepaald hoe de waarde er "als string" uit moet gaan zien

Idd.

[Verwijderd]

Hoe die waarde er uit gaan ziet is mijnziens een taak van je presentatielaag, immers hoe presenteer je je string. Het enige wat je DAL hoeft te doen is de data teruggeven, en je business logic de eventuele bewerkingen. Maar hoe het er uiteindelijk uit gaat zien hangt af van je presentatie.

[MaxxRide]

Dat is dus een punt van discussie. Wie weet er meer over de presentatie van de gegevens in het object; de verantwoordelijk nl het object of degene die waarden gaat presenteren en daardoor een null value in de database in een integer wellicht als 0 presenteerd terwijl dit een lege string zou moeten zijn .

[Verwijderd]

Verwijderd schreef op maandag 30 mei 2005 @ 20:32:
Hoe die waarde er uit gaan ziet is mijnziens een taak van je presentatielaag, immers hoe presenteer je je string. Het enige wat je DAL hoeft te doen is de data teruggeven, en je business logic de eventuele bewerkingen. Maar hoe het er uiteindelijk uit gaat zien hangt af van je presentatie.

Ok, hoe het eruit ziet is een probleem van de UI. Geef ik volledig gelijk. Maar ik vind het ook een beetje onnuttig om overal in je UI te gaan controleren of een bepaalde waarde niet null is en dan pas deze waarde te tonen.

[MaxxRide]

Volgens mij is de UI inderdaad verantwoordelijk over hoe het eruit gaat zien. Maar dan in de zin van waar staan de editboxen, hoe presenteer ik de fouten vanuit de businesslayer etc. etc. De formattering van de data lijkt me een businesslayer issue, dit is de enige die hier wat over kan zeggen.

[foske]

MaxxRide schreef op maandag 30 mei 2005 @ 20:29:
[...]


Of van je businesslayer die bepaald hoe de waarde er "als string" uit moet gaan zien

Dit is op zich wel netjes, en dit heeft ook een punt:

Verwijderd schreef op maandag 30 mei 2005 @ 20:41:
[...]
Ok, hoe het eruit ziet is een probleem van de UI. Geef ik volledig gelijk. Maar ik vind het ook een beetje onnuttig om overal in je UI te gaan controleren of een bepaalde waarde niet null is en dan pas deze waarde te tonen.

maar,

je hebt denk ik twee uitgangspunten:
1. Je zegt dat je BO verantwoordelijk is, want het BO gaat over de inhoud van een object en welke tekst er komt te staan, is een inhoudelijk vraagstuk.
De presentatielaag zorgt voor formatting en layout, meer niet.

2. De presentatielaag is verantwoordelijk, want de waarde van een BO attribuut is null, en formatting van deze waarde null wordt in de presentatielaag bepaald. (Zet ik de waarde uberhaupt wel neer in mijn presentatie, als deze null is, of zet ik een aparte tekst neer?).

Dit doe je feitelijk ook als je een tabel op je scherm wilt zetten. Heeft deze geen rows (rows = null even kort door de bocht), dan wil je of de tabel niet weergeven, of een andere tekst neerzetten dat de tabel geen gegevens bevat.

Het is denk ik dan toch een UI kwestie, enige nadeel is, iedere check of de waarde niet toevallig null is. (hoewel dit natuurlijk eenvoudig in een aparte methode van je presentatielaag te zetten is).

[ Voor 5% gewijzigd door foske op 30-05-2005 21:20 . Reden: Tegenstrijdig gebrabbel... ]

[MaxxRide]

Tja nog een probleem als je het in de UI doet. Stel je zegt GetNumber die is gedefinieerd als int. Later bedenk je dat dit te weinig ruimte is en ga je over op een long. Daar ga je, je mag alle code aan gaan passen, terwijl als je had gezegd als string dan had je je UI tenminste niet aan hoeven passen.

[foske]

MaxxRide schreef op maandag 30 mei 2005 @ 21:11:
Tja nog een probleem als je het in de UI doet. Stel je zegt GetNumber die is gedefinieerd als int. Later bedenk je dat dit te weinig ruimte is en ga je over op een long. Daar ga je, je mag alle code aan gaan passen, terwijl als je had gezegd als string dan had je je UI tenminste niet aan hoeven passen.

Tja, dan kan je beter alles maar als string doen, dan heb je dat probleem nooit
Denk niet dat dit een argument mag zijn bij je keuze.

[MaxxRide]

Denk ik dus niet. Daar waar je de waarde gaat presenteren heb je vaak een string (eigenlijk zijn alle UI properties zo een beetje string properties) nodig.

In je BO praat je uiteraard met de native waarde.

[lvmeijer]

MaxxRide schreef op maandag 30 mei 2005 @ 21:11:
Tja nog een probleem als je het in de UI doet. Stel je zegt GetNumber die is gedefinieerd als int. Later bedenk je dat dit te weinig ruimte is en ga je over op een long. Daar ga je, je mag alle code aan gaan passen, terwijl als je had gezegd als string dan had je je UI tenminste niet aan hoeven passen.

Daar heb je nou refactoring voor. Voor Visual Studio 2005 is er zelfs een gratis tool van Developer Express (grote partij voor .NET componenten). Je kan het vinden op http://www.devexpress.com/vbrefactor/. Het is gratis dankzij een nieuwe samenwerking van DevExpress met Microsoft.

Oh ja... merk op dat deze tool alleen werkt met VS 2005 en VB.NET. Hij is er ook voor VS.NET 2002 en 2003 en voor C#... maar dan moet je betalen. Wat ik bedoel te zeggen... als je wat (commercieler) programmeert en dit soort (herhaaldelijke) dingen wilt voorkomen... kies je voor extra tools. Ik wel in ieder geval, maar dat is misschien persoonlijk. Oke... je kan ook je design aanpassen...

[dingstje]

MaxxRide schreef op maandag 30 mei 2005 @ 21:11:
Tja nog een probleem als je het in de UI doet. Stel je zegt GetNumber die is gedefinieerd als int. Later bedenk je dat dit te weinig ruimte is en ga je over op een long. Daar ga je, je mag alle code aan gaan passen, terwijl als je had gezegd als string dan had je je UI tenminste niet aan hoeven passen.

Als je er achter komt dat je een long nodig hebt ipv een int is er duidelijk iets mis gelopen in de ontwerpfase (niet dat ik veel moet zeggen ).

Fossie:
Als je dit in DAL gaat doen, betekent dit dat je niet meer het type int of Date kan gebruiken. Nu is het zo dat er waarschijnlijk nooit gerekend gaat worden worden met deze waardes, maar is het niet netter om deze waardes pas om te zetten in een string zodra ze in bijvoorbeeld een label gestopt worden?

Houd er ook rekening mee dat als je gaat gebruik maken van SOAP en je wilt een datum doorgeven dit zeer makkelijk is met een type Date (SOAP specifieert een bepaald formaat om datums in op te slaan). Je zou dan namelijk kunnen krijgen: omzetten naar string (mogelijk dataverlies omdat je ervanuit gaat dat de gebruiker het aantal seconden toch niet hoeft te weten, een andere applicatie die je webservice gebruikt mss wel), en dan om door te geven aan je webservice toch weer omzetten naar Date. Netste lijkt mij ook om alles pas om te zetten naar string wanneer het nodig is (in de UI layer dus).

[Verwijderd]

Ja, ik denk dat ik het daar ook bij ga houden. Het is nogal onlogisch om dit in je BusinessLayer te doen. Iets in mij zegt dat althans.

[MaxxRide]

Ik blijf erbij dat het helemaal niet onlogisch is. Voor het praten met je UI definieer je properties die de waarden als string teruggeeft.


Voor je SOAP gebruik je uiteraard je native waarden, immers je hebt dan een RPC en je wilt dus aan de andere kant met het object praten niet met de string representatie ervan.

Maar goed, er zijn meerdere wegen die naar Rome leiden

Als je er achter komt dat je een long nodig hebt ipv een int is er duidelijk iets mis gelopen in de ontwerpfase (niet dat ik veel moet zeggen ).

Tja als een systeem een aantal jaar draait kom je dit nogal eens tegen. De aanname dat dit soort digen tijdens ontwerp moeten worden bedankt gaan nou eenmaal niet altijd op. Soms veranderen de specs van een systeem nou eenmaal.

[BertS]

MaxxRide schreef op maandag 30 mei 2005 @ 21:53:
Ik blijf erbij dat het helemaal niet onlogisch is. Voor het praten met je UI definieer je properties die de waarden als string teruggeeft.

En wat is dan jouw antwoord op dingstje in "[.net/alg] In welke Layer de Null waarde..."?
Want volgens jouw stelling bepaal je dus in de BL of de gebruiker wel/niet seconden te zien krijgt. Dat lijkt mij nu net weer een taak van de UI.
Daar komt bij dat er zeker wel GUI-elementen zijn die wat anders dan een string verwachten (datepicker eet liever een datum dan een string ;-)), ga je dan weer vanaf de string naar het juiste type converteren?
Het lijkt mij juist dat de BL voor elk veld een datatype moet aanbieden wat de waarde van het veld zo goed mogelijk definieert (dus geen afrondingen, afbrekingen e.d.), en waarmee een UI normaliter overweg kan.

[D4Skunk]

Wat ik wel zou doen in de business-layer, is System.DBNull.Value omzetten naar null.

[Verwijderd]

Dat doe je in een onderdeel van je controller, namelijk binnen een PropertyEditor. De waarde van je data object moet expliciet 'null' blijven dus daar blijven we netjes vanaf.

[exyll]

Dit soort checks doe je in alle lagen die je onderscheid. Op die manier zijn fouten in een zo vroeg mogelijk stadium op te vangen en kun je het proces bij sturen (indien je dat wilt) en scheelt dit I/O met onderliggende lagen/services.

Je kunt het wat flexibeler maken door b.v. met xml te weken en de xml data tegen je xml schema te houden voor validatie. Dan kun je in de toekomst makkelijker data structuren aanpassen.

[MaxxRide]

bee-es schreef op maandag 30 mei 2005 @ 22:24:
[...]

En wat is dan jouw antwoord op dingstje in "[.net/alg] In welke Layer de Null waarde..."?
Want volgens jouw stelling bepaal je dus in de BL of de gebruiker wel/niet seconden te zien krijgt. Dat lijkt mij nu net weer een taak van de UI.
Daar komt bij dat er zeker wel GUI-elementen zijn die wat anders dan een string verwachten (datepicker eet liever een datum dan een string ;-)), ga je dan weer vanaf de string naar het juiste type converteren?
Het lijkt mij juist dat de BL voor elk veld een datatype moet aanbieden wat de waarde van het veld zo goed mogelijk definieert (dus geen afrondingen, afbrekingen e.d.), en waarmee een UI normaliter overweg kan.

Je biedt je property d.m.v. een override functie in meerdere datatypen aan aan de gebruiker. Voor de formattering van een date object met of zonder seconden zou je een parameter aan de functie kunnen meegeven. Ook daar gebruik je dan een overridden functie voor een met de default waarde een met de formatstring.

Als reactie op dingstje heb ik al vermeld dat je bij SOAP 'gewoon' de native code aanbiedt. Je biedt in je BO dus een diversiteit aan manier aan om de data te formatteren.

Zoals ik al zei: er zijn meerdere wegen die naar Rome leiden.

[ Voor 8% gewijzigd door MaxxRide op 31-05-2005 10:41 ]

[Verwijderd]

MaxxRide schreef op dinsdag 31 mei 2005 @ 10:40:
Je biedt je property d.m.v. een override functie in meerdere datatypen aan aan de gebruiker. Voor de formattering van een date object met of zonder seconden zou je een parameter aan de functie kunnen meegeven. Ook daar gebruik je dan een overridden functie voor een met de default waarde een met de formatstring.

Dus nogmaals, een propertyEditor.

[MaxxRide]

Als je daarmee meerdere properties bedoelt in het BO ja.

Ik begrijp trouwens niet waarom je dat in de controller zet. De controller is puur om berichten naar het model te sturen, het model te controllen. Een view doet volgens mij de presentatie. Dat is iig mijn interpretatie van het MVC pattern.

Zie ook http://ootips.org/mvc-pattern.html

[ Voor 8% gewijzigd door MaxxRide op 31-05-2005 11:31 ]

[D4Skunk]

MaxxRide schreef op dinsdag 31 mei 2005 @ 11:29:
Als je daarmee meerdere properties bedoelt in het BO ja.

Ik begrijp trouwens niet waarom je dat in de controller zet. De controller is puur om berichten naar het model te sturen, het model te controllen. Een view doet volgens mij de presentatie. Dat is iig mijn interpretatie van het MVC pattern.

Zie ook http://ootips.org/mvc-pattern.html

Misschien moeten we op zoek naar een andere benaming...
Facade iemand ? Of bestaat er zoiets als een presentation layer ?

Verwijderd schreef op dinsdag 31 mei 2005 @ 09:49:
Dat doe je in een onderdeel van je controller, namelijk binnen een PropertyEditor. De waarde van je data object moet expliciet 'null' blijven dus daar blijven we netjes vanaf.

Normaalgezien gebeurt de omzetting van DBnull.Value naar null bij de overgang van je datalayer naar je business layer imho, maar gezien de TS slechts twee layers wenst te gebruiken, zou ik toch aanraden om dit in de Business layer te doen, en niet in de ui layer.

[Verwijderd]

Dat is juist helemaal raar want het is logisch om je controller bij de view te betrekken op het moment dat je maar twee lagen hebt. Verder is het veranderen van de waarde van een bepaalde property helemaal niet aan je businesslaag, die moet gewoon de werkelijke waarde bevatten.

[MaxxRide]

@marvleth: nu ben je me kwijt. Het gaat om twee zaken, hoe werkt het MVC pattern en waar zet je de waarde om in een string.

Ik ben nog steeds voor BO omdat deze het meeste inzicht heeft over de conversie. Holub heeft hier overigens eens wat over geschreven op javaworld. Zal vanavond eens kijken of ik het artikel kan vinden.

De controller kan overigens op een view staan in het geval van een windows form. Maar goed ik denk nog steeds:
controler -> manipuleert model a/d hand van ingevulde velden ingevoerde knoppen
view -> geeft een weergave op dit model dus invulling van de velden etc.

[D4Skunk]

Zoals ik het bekijk is system.DBNull een dependency uit de database context, en mag deze dus NOOIT als waarde van een property uit je business layer gebruikt worden, anders zit je met de volgende checks overal waar je je business objecten gebruikt, tenzij je explicit al je vars op DBNull gaat initialiseren :

C#:

if (object==null || object == DBNull.Value)

Het lijkt mij persoonlijk niet echt aan te raden om in een form System.DBNull.Value te gebruiken; een form heeft mijns inziens NIETS te maken met de database.

[ Voor 4% gewijzigd door D4Skunk op 31-05-2005 12:00 ]

[Verwijderd]

@MaxxRide

Een ding wat je niet wilt is dat je waardes (properties) van je data objecten veranderd moeten worden om het voor een gebruiker leesbaar te maken. Immers een waarde null moet in je business logica altijd dezelfde betekenis hebben. Je gaat er immers niet controleren op "undefined"/"niet gedefinieerd"/etc. Ik denk dat we het daar iig wel een over kunnen zijn. Deze business logica dient zich ook helemaal niet bezig te houden met dergelijke presentatie zaken.

Dan de view: Ook deze is niet bedoeld voor een dergelijke conversie aangezien een gedeeld object dan in elke view moet worden aangepast als je een null waarde anders wilt weergeven.

Dan blijft enkel de controller over, deze selecteert immers de juiste data en de juiste view. Hier hangen we dus propertyEditors aan data objecten (feitelijk wrappers om de data objecten) die een getValue formatteren naar de gewenste "human-readable" waarde.