Need Your Attention this is General!

[_mubashir]

Hello All! This is a general question and I was confused that on which forum I ask. My product is in C# so it chose this. The problem is that we have some forms on which the control data is populated from the database. Now we need to check for the data coming from database with certian IF statements and then fill the respective controls(textboxes). We are getting the dataset. Now my team member says that we should first put all the dataset Row data into private variables and then perform IF on Private variables and then populate the control with private variables. This is coz it is difficult to write (ObjDataSet.Tables[0].Rows[index]["SomeCol"]) than simply the VariableName in the checks. Now we can have 15-20 columns in a dataset Row, and thus we have to declare 15-20 variables in each form.......Is this approach suitable.....? Please suggest. Thanx in advance Mubashir, Remote Silicon

[darkelv]

There's nothing wrong with pulling the data from the row into variables, though your database, business logics and maybe user interface are all intervined together. But IMO what is better is pulling the data from the row into variables of a class. For example public class Customer { // your private declaration of the variables ie customer name, address, phone // the public accessors of the private variables public validatecustomer(); public void setcustomer(DataRow row); public DataRow Row { get; } } As what you can see, you can add functionalities to the customer class such as populating it by passing it a row, or get the customer as a DataRow, validating it, binding the properties (variable) to controls. It is an object oriented and 2 tier way of doing it, which separate your logics and database from each others. -- modified at 2:45 Wednesday 22nd March, 2006

[Bob Stanneveld]

Hello, How you solve the problem, or if you solve it at all is just a matter of preference. It is indeed tedious to write and it obfuscates your statements. My advice is to create a wrapper class that wraps a row of your database. This can be a simple replacement around the long prefex:

public class SomeWrapper
{
// some constructors and such
public object GetCol(string colName)
{ return ObjDataSet.Tables[0].Rows[index]["SomeCol"]; }
}

Or the wrapper can be a more sophisticated using properties and the like. You can use the wrapper the following way:

SomeWrapper row = new SomeWrapper(ObjDataSet.Tables[0].Rows[index]);
if( row.GetCol("column...").Equals("SomeValue) )
{
// your logic
}

Hope this helps :-D Behind every great black man...             ... is the police. - Conspiracy brother Blog[^]

[mcljava]

There is definitely more than one way to skin the proverbial cat. My take is create a named data set. The when you fill the adapter you are referring to a table and row such as MyTable.AccountNumber[i] instead of Tables[0].Rows[....] If you have signaficant converion between the dataset and the deseried representation in variables then a custom data set make not fit so well. You might be better off dealing with the generic data set. But again I would rather define an Interface with the constants you need to manage the generic data set. Then you can refer to logical index names instead the hard coded table, row or column names. Finally when should you copy the data set to a private data store? Well if the data set is humongous and you are only using a small portion that has to be converted and used by other .CS classes and modules, then it makes sense. Particularly if If you are copying the data set and using the variables all with one class the need is dubious. It is definitely "overhead" to copy a bunch of variables so if you can find a way to directly operate on the data perhaps via a Named Data Set or through an Interface, then your app can drive directly off the data w/o the intermmediate cyles. Good Luck Mike Luster CTI/IVR/Telephony SME

[Bob Stanneveld]

Hello, The two tier approach is asking for trouble in a multi-user application. The approach lacks maintanability since the business logic and the database access is spread across the GUI. A better approach is using at least another layer with your business logic and one layer with your database access code. The principle is to use mappers for your domain objects that shift the data from and to the database and the domain objects for the business logic. The GUI just uses the domain objects. It is a lot of work to get it started, but in the end it pays of when it comes to maintaining and reusing the code. Behind every great black man...             ... is the police. - Conspiracy brother Blog[^]