-
Aug 16th, 2013, 10:01 PM
#1
Thread Starter
Addicted Member
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.
-
Aug 17th, 2013, 12:30 PM
#2
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.
-
Aug 17th, 2013, 02:53 PM
#3
Thread Starter
Addicted Member
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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|