Results 1 to 3 of 3

Thread: Best Practices VB 2012

  1. #1

    Thread Starter
    Addicted Member
    Join Date
    Sep 2006
    Posts
    236

    Best Practices VB 2012

    I'm pretty new to VB2012 having come from years of working with VB6. In VB6 I rarely worked with classes with the occasional exception of using classes for repetitive forms. Since I'm just getting started I want to approach the architecture from the best practice but I am having a little trouble understanding layers.

    One of the first jobs I chose was to fill a combo box with US States. I do not wish to use the wizards - I prefer to code my own connections and readers.

    The first class I created - just to keep the connection string separate and easily located/changed should I wish to change dB later.
    Code:
    Imports System.Data.SqlClient
    
    Public Class ConnectionDB
    
        Public Shared Function GetConnection() As SqlConnection
            Dim connectionString As String _
                = "Data Source=localhost;Initial Catalog=Rentals;" &
                  "Integrated Security=True"
            Return New SqlConnection(connectionString)
        End Function
    
    End Class
    Next I created a second class for the State properties.
    Code:
    Public Class State
    
        Public Sub New()
    
        End Sub
    
        Public Property StateID() As Integer
    
        Public Property StateName() As String
    
    End Class
    I also created another class to handle interaction with the dB

    Code:
    Imports System.Data.SqlClient
    
    Public Class StateDB
    
        
        Public Shared Function GetStateList() As List(Of State)
            Dim stateList As New List(Of State)
            Dim connection As SqlConnection = ConnectionDB.GetConnection
            Dim selectStatement As String =
                "SELECT StateID, StateName " &
                "FROM States"
            Dim selectCommand As New SqlCommand(selectStatement, connection)
            Try
                connection.Open()
                Dim reader As SqlDataReader = selectCommand.ExecuteReader()
                Dim state As State
                Do While reader.Read
                    state = New State
                    state.StateID = reader("StateID").ToString()
                    state.StateName = reader("StateName").ToString()
                    stateList.Add(state)
                Loop
                reader.Close()
            Catch ex As SqlException
                'some notice of failure here
            Finally
                connection.Close()
            End Try
            Return stateList
        End Function
    
    End Class
    This is the code on the main form ...

    Code:
    Private Sub LoadBusinessStateCombo()
            Dim stateList As List(Of State)
            Try
    
                stateList = StateDB.GetStateList
                cboBusinessState.DataSource = stateList
                cboBusinessState.ValueMember = "StateID"
                cboBusinessState.DisplayMember = "StateName"
    
            Catch ex As Exception
                StatusBar.Panels(0).Text = "Failed to load State Combo: " + ex.Message
            End Try
     End Sub
    I understand all that I've done so far and it's working as I intend.

    However, this is a very small section of the application, of course, and I anticipate there will likely be a large number of subroutines/events in the main form by the time all is said and done - after all this just loads one control. It's true I will reuse it elsewhere, but some areas in the app will be much more complex. The app is a single form with 8 tabs for different routines/procedures. It occurs to me that having so many subroutines lumped together makes things harder to debug and somewhat more confusing to understand. I have read about a Data Access Layer which I believe is covered by the classes I have already made. Then I hear talk of a Business Layer which I do not quite grasp. Is it grouping code together in modules? For instance, having a single module to handle the activity when one of my tabs is selected. I can see having the main form call a public sub on a module that then pretty much keeps the work within that module. But I don't know if that would be good form or not. Perhaps the code should just stay on the main form ... I don't know.

    Do most developers use a Business Layer? How do you set up and use a Business Layer? What is the best practice for continuing to code the app?

    TIA
    Ken
    Last edited by SparrowHawk7; Aug 16th, 2013 at 10:07 PM.

  2. #2
    Karen Payne MVP kareninstructor's Avatar
    Join Date
    Jun 2008
    Location
    Oregon
    Posts
    6,686

    Re: Best Practices VB 2012

    The following is for Windows forms projects. We generally have one project for data access, another project for business logic, another for user interface. In recent projects we have moved to WCF (Windows Communication Foundation) projects were many of the data access projects port over with little effort as they are void of forms specific namespaces items. The point is to think thru your class project architecture. We have base projects that have a) multiple classes for dealing with accessing say IBM-DB2 and MS-SQL Server databases b) single data providers were the class is the same as the one in the multi-data provider library (can get interesting when done correctly). Then of course I would advise looking at the Entity Framework also.

    If there are custom controls they may be in the solution if specific to the solution while other custom controls are in a globe team control library.

    In the business layer we have certain rules that are enforced by using Interfaces that force someone inheriting to implement what we want.

    In short the data access level has no business logic or UI, business logic has no direct access to data or the UI.

    Moving to web, WCF projects are meant to be called my Java and is data only, all UI and business logic is on the Java side.

    Do we split things up in every single project this way? No, but never include data or business logic in the UI. There might be two projects, one for the UI, another for data and business layers.

    There are some interesting third party Frameworks also such as CSLA .NET which we have studied and adapted some parts into our stuff.

  3. #3

    Thread Starter
    Addicted Member
    Join Date
    Sep 2006
    Posts
    236

    Re: Best Practices VB 2012

    Thanks for the reply, Kevin. That gives me some stuff to consider and look into. Most everything I see on the net is very specific to a single question but not much goes into program architecture. Back in 1970 when I first started programming in Basic (and Fortran IV) a program consisted of a chronological process with the ability to call subroutines. There were no events, no objects .... not even monitors. Everything was done with a teletype machine. The first computer I worked with was a tabletop HP with a row of switches that were set to the bits and dumped into the 8K (I think) memory and onto the next byte. When we got a teletype machine we could communicate using Basic but that took up a chunk of that 8K - all kind of limited. After that I moved on to an IBM 360 which took up an entire floor of an office building. At that point I started working in assembly language but that architecture is entirely different. I returned to VB6 eventually as a hobbyiest. That was event driven, of course, but OOP was not as developed as it is in VB2012. I've fiddled with C++ over the years so I was exposed to classes but while VB in the old days could be designed to use them, they weren't particularly necessary so I have little experience working with them. I want to keep up with current practices in my programming which is what this question was all about. Thanks again.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width