assume i have a huge input form, which of course representing classes. i need this input to be loaded into the class's instances. this input obviously contains (some very complicated validation) checks, obviously the logic layer contains those input validation already. the question is what am i doing with gui.
should i just, in a very ugly way, just rewrite all those validations in the GUI?
or should i write some statics methods in the logic layer, in use those methods in the gui and in the logic layer, but still creating a duplication of the validating it self (first the gui validate itself, then the logic validate what sent to it)
or should i just assume the gui is okay, surround the relevant code that use the logic layer, with a try block, and then, if exception is thrown, inform the user that SOMETHING is not right (without giving him a chance to know what it is)
or should i expose the exception, in which way i expose to him parameters, classes and namespaces names, which he probably won't understand.
or should i make a special exception class for every single error, and this way inform the user exactly what the problem, but creating maybe hundred of possible exceptions
or should i separate it to general exceptions, which everyone include enum describe the exact content of the error, then catch those exceptions, and by checking the enum inform the user what exactly the problem, but make the app heavier by catching unnecessarily exceptions all the time.
or should i (someone has offered this to me, this isn't my idea, don't shout at me :D) to validate the input in the logic layer, and check it only in the gui (seems to be me absolutely horrible solution :D)
and much more important question - where should i learn such things? usually my instincts are pretty good, but i don't want to unnecessarily invent the wheel.. (i'm pretty sure there already conventions for such basic things you bombed into every day).
thank you very much!
Certainly you should be validating user inputs. If the inputs and validation logic are as complex as you say they are, its even more important to validate the input in the GUI, in a way that makes it obvious to the user what the expected values are, and, if there are any errors, what they are. Bonus points if you can suggest how to fix those errors!
It really doesn't help the user to be seeing exceptions and exception details -- so try to avoid that.
Also, since you're dealing with input validation in the GUI, and bad input is an expectation, and isn't really out of the ordinary, using Exceptions isn't necessarily a good idea. A simple IsValid() method to check whether something is valid or not is preferable. I always follow the rule that states "Exceptions are for Exceptional circumstances".
So if you accept that validation in the GUI is a good thing, then the next question is: How?
You say that you already have a lot of validation in place, but it doesn't sound like your validation logic is available separately. A practice that I've always found useful is to keep the validation code separated from other business logic. That allows you to re-use the validation logic where appropriate, and in this case, would allow you to share the same validation logic between your business objects and the GUI. There are, obviously, many design approaches and frameworks to do this, but the fundamental principle is a "separation of concerns" - keep the validation logic separate, and make it available for use. You seem to be thinking along the same lines when you say "write some statics methods in the logic layer, in use those methods in the gui and in the logic layer", and that's an approach that is proven to work.
Just for clarity's sake -- I'm not suggesting you put the validation logic in the GUI itself. Rather, make the validation logic available to be used by the GUI. The only part of the validation that should be in the GUI is the part that takes the inputs from the user (to submit to validation) and the part that displays the results of the validation (to the user).
Edit:
I don't want to sound like a shill for a particular design philosophy, but lately I've been doing more work using Domain Driven Design principles. I've found it works very well, and it addresses many of the questions you're asking. There are a few questions on SO that give more details on what it is and where some resources are:
https://stackoverflow.com/questions/1353742/domain-driven-design-ddd-readings
What is domain driven design?
Also, have a read here: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/02/15/validation-in-a-ddd-world.aspx
Edit 2:
Also a useful (and related) read: Business Objects, Validation And Exceptions