Results 1 to 6 of 6

Thread: Classes and methods in business tier?

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    May 2002
    Posts
    1,602

    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

  2. #2
    PowerPoster hellswraith's Avatar
    Join Date
    Jul 2002
    Location
    Washington St.
    Posts
    2,464
    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.

  3. #3

    Thread Starter
    Frenzied Member
    Join Date
    May 2002
    Posts
    1,602
    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

  4. #4

    Thread Starter
    Frenzied Member
    Join Date
    May 2002
    Posts
    1,602
    Yeah sorry I posted without noticing your reply


    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

  5. #5

    Thread Starter
    Frenzied Member
    Join Date
    May 2002
    Posts
    1,602
    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

  6. #6
    Lively Member
    Join Date
    Jan 2002
    Location
    Wiltshire/Somerset
    Posts
    68
    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

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