Classes and methods in business tier?

I have a method in my data tier which returns a dataset of all the contacts. In the business tier I have Load() and Save() methods in the Contact class. When I save a contact I simply read the data from the presentation tier into a contact object and persist that contact to the data tier (via the business tier Save() )


But when I need to list all contacts ina datagrid, should I then write the Load method in the business tier so it returns a dataset? Or is there better way? I kinda jumps one step when I don't set the properties of the contact object... Things like error controling and such.

But if I load all data into an object, how can I then bind that object to the datagrid? Perhaps I need to implement some kind of interface that I can use in the Load() method? I want to write;

dim dg as new datagrid
dim con as new contactcollection()

dg.datasource = contactcollection.load() <--- I don't want to return a dataset but rather a collection of contact objects, loaded from the database... and that have been filtered through the properties of the object.


I think my contactcolletion need to implement some knd of interface that allow me to bind it like that..?

kind regards
henrik

Do you have a strong typed collection class to hold the custom objects? If you do, and it is derived from CollectionBase, it becomes bindable. Now, you may have to implment the IBinding interface in order to get all features to work in the grids. Give me a few hours until I get into work, I will show you what I have for that.

I want to illustrate another problem I have in this area...

Imagine you have a vehicle sales web app. In the business tier you have defined these classes

base class Vehicle

class car
class mc
class boat
all inherits from vehicle

class sport_car inherits from car
class sailboat inherits from boat
class motorboat inherits from boat



Now I define a collection class for the vehicle class so I can hold numerous veichles in a collection.

the base class vehicle contain methods for save, load etc.

How should these classes be separated in the datalayer?

Lets say I have a webform called "add vehicle"

Where should I add all the logic needed to separate a boat from mc and car? I mean if it's a car I would create a car object and persist it to the db..

Is this the correct place to create a vehicle factory (factory pattern) that returns the correct object to the presentation tier?

How do I keep these vehicles separated in the database? I have a clear view how to model the app in vb.net but what should the db object model look like???? How do I keep a car from a sport car separate in the db? Not all properties are alike so I can't just have a car table and add a bool for sportcar(true-false)


any help in this matter is greatly appreciated!

I know it's heavy stuff, but I think all vb devs can benefit from discussions like this

kind regards
Henrik

Yeah sorry I posted without noticing your reply :blush:


Yes the easiest thing would probably be to inherit from colletionsbase, however I stumbled across an article that suggested that I create an serializable class that implements the IEnumerator and ICollection interfaces. While this is not a difficult thing to do, a quicker approach would be helpful...

My dilemma also concerns wether or not I should use TYPE SAFE collections.. is this needed in 3 tier OO applications? But since in my example all vehicles inherit from the baseclass vehicle it is not that bad... although I probably need to typecast if if I have option strict on


kind regards
Henrik:thumb:

Just a thought about mapping my business tier to the database object model. This is easy enough when you have three tables and one or two keys... but in my work I often have applications that consist of about 30 tables and each table have three or four keys. Now things become really painful. Of course still there are objects I can separate, but what is there to do when the relationships become so painfully complex?

For example, let's say I want to show a datagrid of some data based on input parameters and about 6 db tables... How should this be coded in the business tier?

It is much more complex than the example I see everywhere where you want to list a "customer" table... it's easy you have a serializable customercollection that you can bind to your grid

dim oCustCol as new CustomerCollection

mydatagrid = oCust.Load
OR with parameters.. an overloaded Load method
mydatagrid = oCust.Load(txtName.text, txtZip.text)

And there you have it. But what about the "real world" complex situations? I don't see any articles about them... even with the northwind db an advanced business tier could be designed...


kind regards
Henrik

Hi MrNorth

I'm having similar issues with trying to work out where to put code for providing complex DB Table hierarchies.

I've come to the conclusion that the best way to do it (for me anyhow) is to return a hierarchical recordset from the DAL to the business tier. The business tier then processes the recordsets into appropriate objects and collection classes. This is then returned to the presentation tier as a collection class.

Not sure if this is the "correct" way of doing things or even if it's applicable to your situation...but thought I'd share my thoughts anyway ;)

Cheers


Wayne