• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1058
  • Last Modified:

Concepts of Multi Tier VB.NET Application

Hi everyone.

I'm trying to get my head around the processes needed for developing a multi-tier vb.net database application.

In my solution I have three projects - the user Interface (windows app), the business object (class) and the data access layer (class), with references in place (UI refs the BO, BO refs the DAL)

The approach I'm currently trying to take is this:

My data access class contains a dataset consisting of several strongly typed DataTables and TableAdapters, with the relevant methods for retrieving data - UPDATE, INSERT and DELETE statements and methods were automatically generated.

My business layer contains the classes for my business objects, with the relevant properties and methods etc. I want all my business logic / rules to go in here.

My UI then needs to bind to the various business objects.

What I'm struggling to get my head around is how to effectively link the three together.

Currently each of my business classes has a Create method which calls the relevant TableAdapter method to populate a DataTable. Two approaches I've tried from inside this method are:

1: read the column values from the returned datarow and assign the values to the class properties / fields and then return a UserDefined Type to the UI and bind to the Object properties (how to updates to the properties in the UI get back to the database through the DAL)

2: return the DataTable to my UI and somehow bind to that. I'm guessing that this approach wouldn't have the object properties to bind to, but maybe the data columns instead. (How do I apply the business logic to a datatable, it's columns and values?)

The question I have really is this. What is a good, sensible approach for doing this kind of thing? Bear in mind it's not a huge app (at the moment), and I'm all for an easy(ish) life when it comes to coding.

I have more specific questions but that can wait for another day - I'm just trying to get my head around the concepts. I've searched around for answers and there seems to be a lot of discussion about Datasets vs. Business Objects - am I wrong to think that I can / should have both :)

Sorry to ramble. Looking forward to some Expert guidance.



Chris Stanyon
Chris Stanyon
  • 2
  • 2
1 Solution
Chris this is often called an N-Tier application model.  I was about to type out a long drawn out explanation but then I figured I'd google it and I found an article relating to n-tier application design which even shows you how to code a VB.Net application.

It sounds like you have the basic ideas down, but you are having problems implementing them into actual code.  I ran into the same problem in college when I had VB.Net coding courses.  Give a read through this article I link here and this should get you on track, with an example as well, then enjoy schooling all your peers.

Chris StanyonAuthor Commented:

Thanks for the link. I've actually read through that before, and while it gives a reasonable example of the basics on how to code an n-Tier Application, it's not really what I was hoping for.

It doesn't really discuss the concepts of application design, and doesn't touch on business objects at all.

As I said, I have a business objects class and would really like feedback / ideas / comments on possible best practices for populating the business objects and their properties and how to communicate with those business object from the UI.

1: read the column values from the returned datarow and assign the values to the class properties / fields and then return a UserDefined Type to the UI and bind to the Object properties (how do updates to the properties in the UI get back to the database through the DAL)

It sounds like you have the method to get data from a database already set in your DAL, which is really just an array of data.  This of course, all get's done in the DAL.  Not all together useful if there is no way to navigate through that data and for a user to interact with the DAL.  That's the job of the Application Layer.  

So you setup your form, you can use a datagrid object, or you can create text boxes for each column returned by your query and throw in some buttons to do the functions you are asking to perform,   Update Query, Delete Row, Insert Row.

So now we've got a way to get data from the database, and a way for the user to interact with the database.  The business object layer is where you'd code the functions which get executed from clicking those buttons and populate the text boxes, or the datagrid, with the data from the database, and pass the data from the UI textboxes or datagrid to your database.  

Your business layer is just a class though, like a blueprint to build a house with instructions, it doesn't do anything until you build something with it (called instantiating a class).  When you instantiate a class, you start building the home (object).  You build the object by using it's properties to store data, it's functions to retrieve and send data to the database in this example, and then you can start building the house by calling the functions, and methods and storing data in the properties in the instantiated object.

So you'll need to create functions in your business class which update a row, delete a row, and retrieve data, these functions get passed data from your ui text boxes or datagrid.  The buttons on your form, or if you're using a datagrid the actions of tabbing or exiting a cell, are what actually call the business class functions.  The trick here is to remember that you have to instantiate your business class first.  I usually do that in the UI.  

So in your UI you have already created an object of your business class which has all your functions to send data to the DAL and retrieve data from the DAL and perform functions on the DAL.  You then just have to have your button functions or your datagrid actions do the code and direct where to put the output from the business object functions.  

Does this make more sense or have I failed dismally in explaining this concept?  Feel free to chip in EErs!
Chris StanyonAuthor Commented:
Sorry for not commenting earlier - had a few days away :)

I've done a lot of reading up on the various design strategies to implement and think I've found a solution that will work for me.

Basically, I'm including 2 projects in my solution, instead of three that I originally intended - 1 for the presentation layer, and 1 for the data access. In the data access project, I'm using a dataset along with DataTables, TableAdapters and their associated CRUD methods.

For the business logic that I want to apply to my data columns, I'm coding partial classes within the dataset, instead of implementing an entire business object class.

Initially I was thinking of using a middle tier for the business objects and using the dataset to populate them, but the more I read, the more it seems that I should work with EITHER business objects OR a dataset - I've chosen the dataset.

I've had no problem getting the data from the database, but was hoping for some insight into best practice for communicating between the UI (presentation layer), the business objects, and the data access layer.

I guess more experience in this kind of database development will give me more options on which strategies to implement, but for now I think I'm heading in the right direction.

Thanks for your time and comments, but I think I'm going to close this one off without awarding the points. The comments weren't really what I was hoping for.



Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now