same here, case in point in a DAL it is not uncommon to have a save method w/ params like this:

public bool Save(int empNo, string firstName, string lastName, string gender, int positionCode)
{
...
}

so instead of remembering all the params, I use the object itself to be passed"
public bool Save (Employee employee)
{
...
}

Although I like optional parameters(vb.net) I wouldn't like to burden a method with lots of parameters. Having said that however, using stored proc you can't have the same save method as the second one and that you have to pass every value to it. Hopefully future version of Sql will let you pass the table datatype to at least have that same functionality.

I don't like long parameter lists because I like to be able to read code on a "normal" resolution without scrolling sideways. I also don't like using VB's line continuation characters due to the default indentation behaviour and the way the background compiler handles continued lines. As a result I avoid long parameter lists at all costs.

Microsoft has handled the situation well with their EventArgs class. Now each event just has a sender and an eventArgs parameter instead of some of the long lists I remember from VB6 days.

As bonskijr mentioned, the DAL is a common place to find these long lists. I haven't tried implementing it yet but SQL Server 2005 allows you to use .NET classes as a user-defined data type. Perhaps you could pass a custom class to a stored procedure in the same manner as EventArgs.

i remember chris (gwapo) introduces a struct just to encapsulte these primitive types.

yes i rather encapsualte those parameters into one or more ADTs than passing along as   plain strings and ints. Jokiz onced turn me down in using this style Delete(int employeePk), though it might be major modification to my exisitng code, I prefer to refactor my codes into Delete(Employee employee).

thanks.

Delete(int employeePk) i think is more simplistic than passing a whole class to the function since it would only use the integer variable. my usual approach on this is calling the delete method inside the class:

employee.Delete();

wherein employee is the class that has a method called Delete().

I would then access the EmployeeId defined inside my class execute my delete procudure.

yeah.. i guess it all boils down to what pattern you are using. :)