>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).