string truncation
-
Wouldn't it be a better idea to have a model layer that sits in between the data access layer and the GUI. The properties in the model layer would know the limits of their respective database fields, and pass this on via an interface such as IDataErrorInfo or something similar. This way you can have GUI validation.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
Thanks Wayne. Yep, that is the way it seems to be evolving. I already discovered I could make most of my business objects derive from a base class (say DatabaseRecord), which could help taking care of general field information handling. I'd still appreciate an example though, so if you're aware of some article I should read, please let me know. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Thanks Wayne. Yep, that is the way it seems to be evolving. I already discovered I could make most of my business objects derive from a base class (say DatabaseRecord), which could help taking care of general field information handling. I'd still appreciate an example though, so if you're aware of some article I should read, please let me know. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
I have a basic article on the IDataErrorInfo that follows the MVVM pattern Validating User Input - WPF MVVM[^] that should get you started. Good Luck!
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
I have a basic article on the IDataErrorInfo that follows the MVVM pattern Validating User Input - WPF MVVM[^] that should get you started. Good Luck!
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
Ah. That looks interesting. Thanks very much, I'll have to read that in the morning, and apply it right away. :-D
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
jschell wrote:
a much better idea is to validate the data first
In theory sure. However it seems to imply the GUI knows all the database field widths, or alternatively the DB knows how to identify the failing field and pass that on to the GUI. Hence my third question. :doh:
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Maybe I didn't explain well enough, but it isn't a one-off situation that I am trying to resolve. My app holds a number of tables and dialogs; each dialog holds TextBoxes (and other Controls), and the strings entered in the TextBoxes is going to be inserted or updated in the tables. Think of people's first and last name, addresses, phone numbers, a comment line, some preferences, and many more. Right now there is no protection against overflow, as TextBoxes allow an unlimited amount of text to be entered (and the GUI is unaware of the table field widths anyway). So it is at run-time that the users might enter too much text in any of a large number of fields; the fields are quite sufficient for the intended use, but nothing is preventing abuse. So I want: 1. to make sure my app behaves well no matter what the input is; 2. provide detailed feedback where necessary (such as "Phone number cannot exceed 50 characters"). One way to remedy the situation would be to populate, at start-up, some data structures describing all relevant field widths, and pass this to the GUI stuff, so it can check all the lengths and warn the user, before attempting an insert/update. However that seems more effort than elegance, hence me asking about some best practices and/or easy solutions. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Luc Pattyn wrote:
One way to remedy the situation would be to populate, at start-up, some data structures describing all relevant field widths, and pass this to the GUI stuff, so it can check all the lengths and warn the user, before attempting an insert/update. However that seems more effort than elegance, hence me asking about some best practices and/or easy solutions.
Generate the database API from the database schema. At the same time, and in a different API, generate validation classes. That includes length validation and not null validations but does NOT include things like foreign key constraints. The validation classes are used in the database API before attempting to apply the data to the database. They can also be used elsewhere, because they represent their own API. This idiom probably works better in a standard distributed arch versus stand alone but the idea still applies. At any rate that is how I do it and have done it that way for years in a variety of different languages. But that is how I do it so it is "easy". The "best-practice" is still - validate it. How you achieve the validation and insure its correctness is a different matter.
-
Luc Pattyn wrote:
In theory sure. However it seems to imply the GUI knows all the database field widths,
My applications always have a database API. That API would be the place to insert validation including limit checks.
Yes, I am implementing that right now. Thanks. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Luc Pattyn wrote:
One way to remedy the situation would be to populate, at start-up, some data structures describing all relevant field widths, and pass this to the GUI stuff, so it can check all the lengths and warn the user, before attempting an insert/update. However that seems more effort than elegance, hence me asking about some best practices and/or easy solutions.
Generate the database API from the database schema. At the same time, and in a different API, generate validation classes. That includes length validation and not null validations but does NOT include things like foreign key constraints. The validation classes are used in the database API before attempting to apply the data to the database. They can also be used elsewhere, because they represent their own API. This idiom probably works better in a standard distributed arch versus stand alone but the idea still applies. At any rate that is how I do it and have done it that way for years in a variety of different languages. But that is how I do it so it is "easy". The "best-practice" is still - validate it. How you achieve the validation and insure its correctness is a different matter.
That makes a lot of sense. I'm adding a model layer with validation right now; it will not be all automatically generated, however first results are good, and I think it will fit for right now. Anyway, thanks a lot for the insights. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Thanks Wayne. Yep, that is the way it seems to be evolving. I already discovered I could make most of my business objects derive from a base class (say DatabaseRecord), which could help taking care of general field information handling. I'd still appreciate an example though, so if you're aware of some article I should read, please let me know. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
I agree with Wayne, your model should be aware of your data structure and it's limitations. As I always us stored procs that are generated this is a simple excercise, the generator reads the table info from the database meta data and creates the CRUD procs , the model code and the DAL (executes the procs and returns a list<> of the object).
Never underestimate the power of human stupidity RAH
-
I agree with Wayne, your model should be aware of your data structure and it's limitations. As I always us stored procs that are generated this is a simple excercise, the generator reads the table info from the database meta data and creates the CRUD procs , the model code and the DAL (executes the procs and returns a list<> of the object).
Never underestimate the power of human stupidity RAH
Thanks. I'm fully convinced by now that is the right way to do things. And I have implemented parts of it already, the TextBoxes now are fully aware of the field widths through a simple model layer and some dictionaries. While not fully automatic, it seems to work well. :thumbsup:
Luc Pattyn [My Articles] Nil Volentibus Arduum