>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?

There are two worlds, as far as parameter passing goes. Some would prefer to use them as is, while the other half would say to create class properties and simply fill them as needed, then a simple call to the method for the process such as ExecuteMyMethod() with no parameter, thus the code in that method would handle the logistic as per what has been defined at the class level.

For me, I prefer to do things like this:

loData.lSchema = True
loData.nSomething = 2
If Not ExecuteMyMethod()
   Return False
End If

Then, there is a version of those who prefer to pass a parameter but an object so you can put everything you want in the object, as needed, and simply pass it.

When it comes to such situation, I prefer to use the Xml standard, so that is easy to evolve. As far as Web Service, when we want to enhance actual method, that is actually not such a bad idea. You simply ask the client to authenticate, either at the global level, or by passing username, password, and finally the Xml content. So, without changing the declaration call, you can enhance as required. That would be similar to the object. I just do not use object anymore for such.

As far as the need to go an additional step through a class for calling the SP, as others said, if that could be eliminated, it would remove one additional hop of processing. Unless you want to handle specific framework related future enhancements in such class, it might be avoided I would say.

In overall, you do what you feel fits best for you. I prefer to keep the focus on using approaches that can easily be expanded as we move towards the application lifetime. That is mostly why I put all generic logistic in a framework and specific client logistic in a separate dll.