A very simple question about how the GUI is integrated with boolean classes
Let's say I have a huge input form that of course presents classes. I need this input to load into class instances. this input obviously contains (some very complex checks) checks, obviously the logic level already contains these input checks. the question is what am I doing with the gui.
should i just very ugly rewrite all these checks in the GUI?
or should I write some static methods in the logical layer, use those methods in the gui and in the logical layer, but still create duplicate checking of its self (first the gui checks itself, then the logic confirms what is sent to it)
or should I just assume the gui is ok, surround the appropriate code that uses the boolean layer with a try block, and then if an exception is thrown, tell the user that SOMETHING is wrong (without giving him a chance to know what it is)
or should I expose the exception, and how am I exposing it to parameter, class, and name names that it probably won't understand.
or I have to make a special exception class for each individual error, and thus inform the user what the problem is, but create perhaps hundreds of possible exceptions.
or should I separate it from generic exceptions, each of which includes an enum describing the exact content of the error, then catches those exceptions and validates the enum, informing the user exactly what the problem is, but making the application heavier, exceptions all the time.
or me (someone suggested this to me, this is not my idea, don't yell at me: D) to check the input in the logical layer and only check it in the gui (it seems to me an absolutely terrible solution: D)
and a much more important question - where should I learn such things? usually my instincts are pretty good, but I don't want to unnecessarily reinvent the wheel .. (I'm sure there are already conventions out there for such basic things that you bomb every day).
Thank you very much!
source to share
Of course, you have to validate user input. If the boolean inputs and validation logic are as complex as you say, it is even more important to validate the input in the GUI, making 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 these mistakes!
It doesn't really help the user see exceptions and exception details, so try to avoid this.
Also, since you are dealing with input validation in a GUI, and bad input is an expectation, and this is not entirely unusual, using Exceptions is not necessarily a good idea. A simple method IsValid()
for checking if something is valid or not is preferred. I always adhere to the rule that says "Exceptions for exceptional circumstances."
So, if you agree that GUI validation is good, then the next question is How?
You say you already have a lot of validations in place, but it doesn't seem like your validation logic is available separately. A practice that I have always found helpful is to keep the validation code separate from other business logic. This allows you to reuse validation logic where needed, in which case it will allow you to use the same validation logic between your business objects and the GUI. Of course, there are many design approaches and wireframes for doing this, but the fundamental principle is "separation of concerns" - keep the validation logic separate and make it available for use. You seem to think so when you say "write some static methods in the logical layer using these methods in the gui and in the logical layer" and that the approach,which has been proven to work.
Just for the sake of clarity - I'm not suggesting you put the validation logic in the GUI itself. Rather, make the validation logic available for use by the GUI. The only part of the validation that needs to be in the GUI is the part that takes input from the user (to send for validation) and the part that displays the validation results (to the user).
Edit:
I don't want to sound like a shill for a specific design philosophy, but lately I have been doing more work using Driven Driven Design principles. I found it to work really well and it addresses many of the questions you ask. There are several questions on SO that give more details on what it is and where some of the resources are:
https://stackoverflow.com/questions/1353742/domain-driven-design-ddd-readings
What is Domain Design?
Also read here: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/02/15/validation-in-a-ddd-world.aspx
Edit 2:
Also helpful (and related) to read: Business Objects, Validation and Exceptions
source to share
I just finished doing very similar things on a project at work. I had 3 rather large forms and a lot of classes representing the data that I needed. Each class had a bool IsValid () method.
When the user clicks the save button, a method is called that creates all classes from the form input elements. Each property has a very simplified validation (type, default values if not given, etc.). After all the classes are created (as a tree, like a structure - one top-level class containing many other classes), the IsValid method is called on the parent element, which in turn calls IsValid on all of its children.
If IsValid returns False, the Errors property for the parent is set with the Errors parameters of all its children that failed to cause the call to IsValid. Then I show the errors in a user-friendly way.
However, there were a few cases where I needed to validate certain criteria before clicking the save button, which I provided to the methods for the respective classes.
I really don't think you should be putting validation in a GUI class at all. Each class should be responsible for its own validation requirements. However, I believe it is useful to use a graphical interface to provide "hints" to the user as to which form regions are needed, such as using change events to enable or disable parts of the form.
I think, in general, it's a good idea to write all your logic and classes in such a way that you don't need a GUI. What if you want to create a console interface instead of Windows Forms? You should be able to exchange one for the other without changing existing business classes.
source to share
This is a great question. The idea of placing validation in the data layer is a classic OO concept, but when the rubber hits the road it can be awkward. I like the idea of introducing validation rules for an object into my own class so that they can be reused; however, there is more to consider.
I usually take a layered approach to data validation, with the top (presentation) layer containing the most complex and useful code. At the middle and data tier, validation is based on validating assertions and throwing exceptions when invalid data occurs. The idea is that you expect the presentation layer to fully validate the data, but in the event that invalid data passes through you, you want to protect the business logic and provide good diagnostics. You definitely don't want to show the unhandled exception to the user, but it's helpful to keep information about the exceptions so you can get to it. For example,you can write an exception trace to a log file and / or send it to yourself in an email and / or display it to the user in an appropriate context if you think the user can handle it.
When you consider the specifics of data validation, the classic idea of creating an object that "knows" how to validate itself becomes less useful than it first appears. Each level of validation is addressed differently. Even though core business rules govern checks at all levels, the response to invalid data differs depending on the context of the code. The main difference is that at the presentation level, you really want to focus on communicating clearly with the user and creating a good user experience in the face of invalid data. It makes sense that this code should be embedded in separate screens and controls.
It makes perfect sense to reallocate simple, atomic business rules to simple functions or constants in validation classes. You can also put these rules in static functions of your data class classes, as you suggest. The main thing is to define the verification rules only once. For example, if your application limits a value between 10 and 100, the constants 10 and 100 should appear only once in your code. But these constants or a simple range checking function will be used from several checking functions at different levels.
In the related section, you can also define validation assemblies filled with classes, with only validation constants and simple validation functions. These validation assemblies can then be loaded into SQLCLR and used to validate the database layer. Thus, the same test definitions can span the entire system down to the database level.
source to share