 | |
Re: Where to do database/info validation
Dotnet Distributed Applications microsoft.public.dotnet.distributed_apps
 |
| | Thread Tools | Search this Thread | Display Modes |
#1
 
| |||
| |||
|
Re: Where to do database/info validation -
06-29-2003
, 02:55 AM
|
-----Original Message----- Because having a integrity problem in the database is the worse thing that can happen to you  , so you need to be sure it cannothappen. If you rely on your application to do the right thing (checking the constraints, or making sure that all the foreign keys are correctly set by using combo boxes or something similar), then you depend on the developer, and that's never good, as we developers usually forget about things. Also, if there is any other application that needs to update the data, then you'll have to also make sure that the other application does the things right too. You'll sleep better if you have the integrity constraints correctly set in your database. Regards, Andres Aguiar www.deklarit.com "Ice" <ice (AT) nospam (DOT) com> wrote in message news:e#ks8ezNDHA.2768 (AT) tk2msftngp13 (DOT) phx.gbl... I agree with most everything said here. I have more of a philosophical question regarding fk constraints. If you are going to preemptively check for such constraints, why build them into the database? ice "Andres Aguiar" <a a g u i a r _at_ d e k l a r i t.com> wrote in message news:uD6TzCyNDHA.2176 (AT) TK2MSFTNGP12 (DOT) phx.gbl... For the string length/null values, you have the following options: - Create a ValidateEntity(EntityObject) method that is called from the UI layer and the BL layer that performs validations that don't need to access the data access layer. - Have the EntityObject (the object where you store the data that you'll send to the BL layer) perform the validations. This is the approach you would use if the EntityObject is a DataSet, as you can set .MaxLength and AllowNull properties to DataSet's columns About referential integrity constraints: - If you want to give the user a meaningful error, then you should check the constraint yourself, because parsing the message is not a good solution. It depends on the language of the database server, the database server version, etc. - You can check before deleting the row, or you can try to delete the row, and if you get an error, check the constraints yourself and see why it happened. Regards, Andres Aguiar www.deklarit.com "TEK" <trondeirikkolloen (AT) hotmail (DOT) com> wrote in message news:uRboZ6wNDHA.2320 (AT) TK2MSFTNGP12 (DOT) phx.gbl... Hello I'm having an issue I'm wondering about. I'm desining an application that is using entity objects and data layer wrapper objects to store, retrive and work on the entities against the database. My business layer (where the entities is located) contains business logic as ensuring correct rights, doing calculations and so on. My question is: where is the correct place to do checks like: - length of text strings - null/non-null values - referencial integrity with delete A example scenario: A user reguests to delete an movie from a movie database. The movie is used by a movie-review, therefore it may not be deleted. What would be the correct method: a) Check the reference in the GUI layer and present the user with a informative message box, not ever try to delete the movi. b) Check the reference in the Business layer, throwing an exception with a good error description. The GUI layer would catch the exception and show the message to the user. c) Catch the database exception in the data layer, try to analyse the exception to localize the error and throw a hopefully user friendly message that is finnally handled in the GUI layer d) Catch the database exception in the business layer, try to analyse the exception to localize the error and throw a hopefully user friendly message that is finnally handled in the GUI layer Other possibilities? regards, TEK . |
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.