Hey Bonnie,
Another quick question...

In your data class below, how would you, say, insert a new customer? Would you create a method like so (I was going to try to do it in C#, but decided against it :-)):

Public Sub InsertCustomer(ByVal emplFName as String, ByVal emplLName As String)
     'Do insert logic with parameters
End Sub

or like so:

Public Sub InsertCustomer(ByVal dsData As MyDataSet)
     'Do insert logic with values in dataset
End Sub

I was doing it using the first method, but saw another message board where somebody was complaining about how another developer was doing it that way. Or maybe I am doing too much thinking, and not enough doing and learning from experience.

Anyway, thanks for the 3-tier sample you posted. I printed it out and it's lying on my desk, and everything I start trying to overthink my code I stop and review it.

>Hey Mike,
>
>I've posted this before, but I guess it bears repeating. Here's the basic architecture we use (notice that the Typed DataSet that gets passed between all the layers):
>
>To simplify, think of three different projects/dlls in your solution. MyUI, MyBiz, and MyDataAccess (I'd actually throw in a 4th one, MyWebService, but let's not complicate matters at this point. Oh wait, I'd have a separate DataSet project too, but as I said, let's keep it simple for now). In your MyUI project, you'd have all the different forms that you plan to use in your UI. The same for MyBiz and MyDataAccess projects, all the different Biz classes and DataAccess classes.
>
>So, to start, your form would be similar to this (to get your data when the form first opens):
>

>using MyCompany.Business.MyBiz;
>
>namespace MyCompany.WinUI.MyUI
>{
>  public class MyForm : MyBaseForm
>  {
>    private long          CustomerKey;
>    private MyDataSet     dsData;
>    private MyBizCustomer oBiz;
>
>    public MyForm(long key)
>    {
>      this.CustomerKey = key;
>      InitializeComponent();
>      this.FillData();
>    }
>
>    public void FillData()
>    {
>      // To simplify, I'm directly calling a Biz class.
>      // In reality, I use a Web Service here instead
>      // which in turn calls the Biz class.
>
>      oBiz = new MyBizCustomer();
>      dsData = oBiz.GetCustomer(this.CustomerKey);
>    }
>  }
>}
>

>Now in your MyBiz project, you'd have a Biz class:
>

>using MyCompany.DataAccess.MyDataAccess
>
>namespace MyCompany.Business.MyBiz
>{
>  public class MyBizCustomer
>  {
>    private MyDataSet dsData;
>
>    public MyDataSet GetCustomer(long CustomerKey)
>    {
>      MyDataAccessCustomer oDA = new MyDataAccessCustomer();
>      this.dsData = oDA.GetCustomer(CustomerKey);
>
>      // if you have other Biz things to do to this customer
>      // do it here before returning the DataSet
>
>      return this.dsData;
>    }
>  }
>}
>

>And, lastly, in your MyDataAccess project, you'd have this class:
>

>namespace MyCompany.DataAccess.MyDataAccess
>{
>  public class MyDataAccessCustomer
>  {
>    public MyDataSet GetCustomer(long CustomerKey)
>    {
>      // Here's where you'd put all the SqlCommand and DataAdapter stuff
>      // and fill your DataSet.
>
>      return dsData;
>    }
>  }
>}
>

>
>
>Now, that's the "simple" version, just to get the concept. Let's take it a step further:
>
>We have 4 "layers" ... UI, Web Services, Business, Data Access.
>
>These are more than 4 projects, because each layer is further broken down by module. Let's take the DataAccess layer as an example:
>
>As in all our layers, there are DataAccess parent classes from which all DataAccess classes inherit. These parent classes have all the basic functionality needed for DataAccess and we consider it part of our "framework" ... it has it's own project. Each module in our app has a separate DataAccess project. So, we'll have a DataAccess.Personnel project and a DataAccess.Inspection project, etc. and the classes in those projects inherit from the parent classes in the "framework" project. (As you probably know, these separate projects become separate .DLLs).
>
>The Business layer got a little more complicated, but the architecture of it is the same. We actually have 2 Business layers ... server-side and client-side. The server-side classes remain on the server where they are accessed from the Web Services. The client-side classes are brought down to the client from the server to be used by the UI classes, but they can also be used on the server.
>
>
>~~Bonnie
>
>
>
>>>We pass around DataSets, some developers pass around Biz objects.
>>
>>Hey Bonnie,
>>So, for example, if you were passing a collection of employees from your data layer back to your UI to, let's say, populate a datagrid, would these be the steps you follow (it's Saturday night, and my mind doesn't work very well on the weekend, so sorry if I say something that doesn't make much sense...)
>>
>>-Populate your strongly typed dataset in your data layer in a shared function that returns your strongly typed dataset type.
>>-In your biz class, have a member with a type of your st dataset which gets loaded from a method.
>>-In your biz class, have a property of your st dataset that the UI refers to?
>>
>>Sorry about the basic questions. I have been working with custom collections and was really starting to "get" that, but then I wanted to bind my collection to a datagrid and became frustrated at how complicated it seemed.