The Book of Visual Studio .NET - A Visual Basic .NET Crash Course, Page 4
While the Visual Basic compiler used a file's extension to determine what type of project file it was, Visual Basic .NET implements all code through classes. All Visual Studio .NET needs to know is the language the file is written in. Project groups in Visual Studio have proved to be a powerful tool for managing, building, and debugging multiple project solutions. Visual Studio .NET replaces the Group Project with a Project Solution, which is one or more projects and the supporting files. Because solutions actually contain projects and items, they are often referred to as Solution Containers. And, because projects also contain files, it should come as no surprise that projects are referred to as Project Containers.
Solutions and project files each have their own extensions so that Visual Studio .NET knows what kind of container they are:
- .sln: The file extension of a solution file which maintains all solution specific information.
- .suo: The file extension of all Solution User Options files which maintains all of the user's preference information for the solution.
- .vbproj: The file extension of all Visual Basic project files.
- .vb and .cs: The file extensions of Visual Basic .NET and C# files, respectively. This is a significant improvement from previous versions of Visual Studio when forms, classes, and other components were given component specific file which offered no clue as to the language used to build the file. Project items built using a specific language will always have that language's file extension, thus allowing Visual Studio .NET to know which compiler it must use. (For additional information on file extensions of project items, refer to the MSDN article entitled, "File Types and File Extensions in Visual Basic and Visual C#".)
One of the more interesting Windows and Web Form improvements is the ability to alert the user of exceptions without interrupting them until they press a button that performs validation, providing better overall user experience. The ErrorProvider component is a non-visual component that allows you to perform data validation on form controls. If a data violation occurs, you can set a message to be displayed as a tool tip near the offending control.
Ideally, you should implement data validation, a type of business rule enforcement, at the lowest common layer. The most ideal place to do so is at the database level because this is the only application layer that cannot be bypassed. Furthermore, rules enforced here are not duplicated as they would be if you implemented business rules in the presentation layer. For example, if a name can be equal to or less than 20 characters and the rule is implemented in the presentation layer, then every form that supports the use of the name must implement the same rule. If the rule is changed, it must be changed in every form that uses the name. This is both sloppy and error prone.
Current technology does not lend itself to this level of data validation very easily; however, over time Microsoft will devise better validation schemes and developers will build custom solutions. The challenge is to provide solid data validation without compromising user experience. To implement data validation in the presentation layer means that we are duplicating business rule enforcement because the same rules are surely implemented in the database as well. Of course the risk is that when the database schema changes, we may miss making the same changes in the presentation layer.
If all business rules are implemented in the Component layer, it is possible to bypass the rules by ignoring the Component layer or building another one that does not implement the rule. In such a case, you have the potential of corrupting data that will be more expensive to repair then it would have cost to devise a sound business rules enforcement schema.
The XML Schema is excellent place to begin looking for sound business rule implementation. By pulling the database schema from the database and persisting it in memory, you can leverage XML Schema to enforce data types and constraints. Also, when building your web page dynamically you can enforce these data specific rules through the ErrorProvider. In this case, you are implementing rules at the business level layer, which were defined in the database at design time; the violation can be made known through the ErrorProvider at the presentation layer. This is the ideal way to enforce data specific business rules; all other programmatic business rules should be implemented in the business level layer. Never enforce business rules in the presentation layer.