Thesis
Application
Events
About us
home page forums

Tutoring

The following contains my notes on how I develop applications in VB.NET using Visual Studio.

The MVC Architectural Pattern

An "architectural pattern" is a design pattern which is a reusable template for how the pieces of a system fit together. This pattern describes how the user interface and business logic in an application is connected. It defines the parts, the specific touch points between the parts, and what types of operations each part should and shouldn't do.

The core idea of the MVC architectural pattern is to keep a clear and distinct separation between the user interface, the business logic, and the "scaffolding" that connects the two. This is what MVC stands for:

  • Model: A representation of the real-world problem in terms of the software system--i.e. the Data.
  • View: A component of the software system capable of visually representing the model--i.e. the User Interface.
  • Controller: A component of the software that translates user input into meaningful operations--i.e. the Program Logic.

In Visual Studio, I separate the MVC parts into classes and prefix the class names to correspond to their function. Thus,

  • Model: These classes are usually prefixed with "biz".
  • View: These classes are usually prefixed with either "frm" or "dlg".
  • Controller: These classes are usually prefixed with "prg".

With a large application I will typically group the MVC classes into separate folders corresponding to the MVC types, such as "forms," "objects," and "programs."

Further Reading: The Arbitrary Geek

Naming Conventions

Object Naming Conventions

The object naming conventions I generally use for Controls, Data Access Objects, and Menus is a throw back to Visual Basic 6.0. Please refer to the following URL for specifics: Object Naming Conventions. I have found it easier to work with than the current one proposed by Microsoft, which is to spell out the object type and tack it to the end of the object reference. For example, an OK button would be "OKButton" and a Help menuitem would be "HelpMenuItem". Instead, I use "btnOK" and "mnuHelp" for these two. I understand that it is a bit more cryptic, but for me it's less typing and easier to locate things.

Methods, Parameters, and Variable names

I use Pascal Case for method names (e.g. Public Class HelloWorld) and Camel Case for variables and method parameters (e.g. ByVal name As String; and Dim fullMessage As String). Terminology:

  • Pascal Case: The first letter of the word is upper case and then each first letter of the part of the word is upper case.
  • Camel Case: The first letter of the word is lower case and then each first letter of the part of the word is upper case.

Occasionally I will use Hungarian notation for parameters and variables (e.g. strName and intMax) to identify the variable type (i.e. "str" for String type and "int" for Integer type). However, I prefer to use meaningful names than to rely on the type description. The only exception are Booleans where I generally prefix them with "Is", "Has", "Can" or "Not".

For Next Loop Variables

On For..Next loop variables I like to use "ith", "jth" and "kth" instead of "i", "j" and "k" variable names that is typically used. It makes it easier to view and search. For example,

     For ith As Integer = 1 to 10
' Do something...
Next

SQL Server Support

I created a few helper and wrapper classes to simply database-related programming using Microsoft SQL Server.