>>Hi everybody,
>>
>>This would be more of a design question. We have a stored procedure with 27 parameters some of them having default values.
>>
>>In our VFP code there is a call for this SP inside a longer procedure with about 15 parameters.
>>
>>I am writing a C# code looking at the current VFP code (basically, I want to get the same functionality).
>>
>>I'd like to put that SP call into a separate method.
>>
>>I've created the method using that same parameters from VFP call (which omits about half of SP parameters) but now when I looked into an SP call I see it has more parameters.
>>
>>So, I'm thinking - would it make sense to rather create a class so I can pass an object to that new method instead? Having 27 parameters in a method looks unwisely and missing some parameters because they are not used in that particular call also doesn't look correct.
>>
>>What do you think the best approach here?
>>
>>Thanks in advance.
>
>Why would having 27 parameters in a method look unwisely? If having 27 parameters is unwise then the SP is unwise itself, rewite it to use a wise number of parameters. IMHO creating a class just to pass parameters is unwise.
>
>Unlike VFP, in C# you can use optional and named parameters, so from the caller you could pass 0 or N of the parameters.
>
>PS: If you like passing object instead, you still don't need to create a class, you could pass an ExpandoObject or Dictionary (which ExpandoObject is behind the scenes).

Ok, I guess I'll go with all 27 parameters in a method (with default values, of course).