[Alg] Business logic 2x specificeren?

[Eelke Spaak]

Ik hou ervan om bij het ontwikkelen van een applicatie aan de onderkant te beginnen; met het specificeren van het databaseschema. In dit schema zitten ook de nodige constraints (foreign key, not null en range) om ervoor te zorgen dat de data in het formaat blijft dat ik wil.

Om de Data Access Layer van mijn applicatie te maken gebruik ik een automatisch tooltje (sql2java bijvoorbeeld) dat de benodigde classes genereert op basis van een bestaande database. Wat nu mijn vraag is: is het wel nodig om de business logic van het checken van waarden nog een keer te gaan programmeren in mijn applicatie, of volstaat het als ik simpelweg fouten van de SQL server afvang en daar een foutmelding van maak?

Waarschijnlijk is de grootste vraag hier een performancekwestie: zorgt het voor (te) veel extra overhead om bij elke invoer een SQL query naar de server te sturen?

[-FoX-]

Over het algemeen is het gewoon *not done* om de validatie van je gebruikersinput rechstreeks aan je RDBMS over te laten. Vind je dit zelf niet een beetje omslachtig?

Je gaat namelijk iedere keer opnieuw naar je database server connecteren en hierop gegevens opvragen.. zoals je zelf al aangaf dus: teveel overhead.
En het is ook een beetje lullig om voor de kleinste checks naar je database te gaan..

[Verwijderd]

Als je business rules in je middleware opneemt:
- hoef je niet elke SQL-foutmelding te mappen naar een logische-fout
- het scheelt best een hoop queries, omdat de meeste databases maar 1 fout per mutatie opgeven zou je voor elk veranderend veld een query moeten doen. Checken welke velden veranderen vereist ook veel middleware.
- niet alle business logic laat zich in SQL vatten

Uitgebreide handelingen of handelingen waarbij Foreign keys betrokken zijn doe ik juist vaak in middleware om fouten bij transacties naar begrijpbare output te mappen. Dir komt vaak voor wanneer de middleware "dik" is en de client een "thin" UI is op een hoop gegevens die in de middleware verblijft.

Ik begin vaak met ontwerpen bij de middleware. OOP sluit hier lekker bij aan als deze in 3GL gebouwd kan worden. Vanuit daar kan ik altijd dingen naar de client of de data laag verplaatsen. Tabellen zie ik als middel om status op te slaan.

[djluc]

Ik vind het eigenlijk wel een interessant punt. Alle verificatie dubbelop doen kost alleen maar tijd. Ik denk dat je wel moet kijken naar de verwerking van de fouten: een ongeldig email adres laat je dat ook door de db controleren? Dan wil je namelijk een nette opmerking op je scherm hebben, en niet zomaar een error in je logs. Een tabel die vol zit wegens systeembeperkingen zou juist weer wel een error mogen genereren. Kortom: is de database wel flexibel genoeg hiervoor? Of wil je dit dan weer zelf gaan implementeren in je applicatie?