Bonnie,

Thank you very much for your message. I will follow your "simple" framework design. I also found a couple of other of yours and Kevin G's posts here that are helpful. I am sure I will be stumbling along the way and will be asking questions. So stay tuned <g>.

Again, thank you.

>Dmitry,
>
>Rich and famous? Me? LOL! I wish!! (Well, the rich part anyway! <g>)
>
>It sounds like you've got the concept down pretty good. But, just for a little more help on the matter, let me post a little blurb that I always use for answering this type of question:
>
>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.MyApp.Business.MyBiz;
>
>namespace MyCompany.MyApp.WinUI.MyUI
>{
>  public class MyForm : MyBaseForm
>  {
>    private long          CustomerKey;
>    private MyDataSet     dsData;
>    private CustomerBiz   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 CustomerBiz();
>      dsData = oBiz.GetCustomer(this.CustomerKey);
>    }
>  }
>}
>

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

>using MyCompany.MyApp.DataAccess.MyDataAccess
>
>namespace MyCompany.MyApp.Business.MyBiz
>{
>  public class CustomerBiz
>  {
>    private MyDataSet dsData;
>
>    public MyDataSet GetCustomer(long CustomerKey)
>    {
>      CustomerAccess oDA = new CustomerAccess();
>      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.MyApp.DataAccess.MyDataAccess
>{
>  public class CustomerAccess
>  {
>    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
>
>
>
>
>>Bonnie,
>>
>>>
>>>I know this was addressed to Einar, but I didn't think you'd mind my $.02 as well. <g>
>>>
>>>One thing that we did on the UI side was to start out by sub-classing all the "main" control objects into one class library file ... you know, things like TextBox, ComboBox, CheckBox, etc. At first these classes had no extra code in them. As we "played" around and experimented with how to do things (this was back in the early days of 2002), we discovered either missing functionality that we put into our classes or functionality that would not be considered missing, but perhaps a different way of doing things than the Microsoft way and we needed to add that functionality to our classes as well.
>>>
>>>I'm not saying that this is a good or a bad way to create your own Framework, but this is the way we started out many years ago.
>>>
>>
>>Thank you for your input. I will follow your road (look at what it brought you: all the fame and fortunes <g>). Seriously, I am "listening".
>>
>>Here is what I decided to do. I will create a "Hello World" framework of my own. (Of course, the long term plan is to expand it, make it commercial and put MM and StrataFrame out of business <g> and become as rich as famous as you are <g>).
>>
>>Here is how I envision my "Hello World" framework. I will describe it from how the imaginary user would "see" the application based on this framework.
>>
>>User will enter something (say, Customer ID or Location City, State) click on a button and all rows matching the selection will be displayed on the form. User will be able to navigate these rows and make changes. Once she makes a change and clicks on the Save button, the information is saved back to the DB.
>>
>>So to accomplish this task I will need DA object - some class that will retrieve rows based on the user criteria and put this rows into a typed dataset, right?
>>
>>Then the typed dataset is passed to the BO, right?
>>
>>Then form controls are bound to this dataset, right?
>>
>>Is this somewhat a correct scenario of how the 3-tier app would work?
>>
>>Thank you all for any input or suggestions.