best practice for passing parameters (form fields) to a method

[Guest]

Hi,
I'm trying to write a update method, in which when the user clicks the
update button the update method is passed 10 form fields. Then a update SQL
is run to update the database.
My question is whats the best way to pass large numbers of parameters into a
method. Ten seems a large number to be passing into and out of a method.

Stephen

 

[Marc Gravell]

It depends what the data represents, but I see no problem with 10
parameters, *as long as* they are clearly named...

However, if the 10 fields represent properties of an entity (as is often the
case with form fields), I would create an object (class) to represent that
entity; the UI would simply read from the form fields, putting the values
into properties on the class; depending on layering (how far my object is
from the DB), I would then either call a Save() method on the object itself,
or call the Save() method on a DAL helper that accepts the (single) object
as a parameter.

Note that this allows the data to be fetched in the same consistent way, and
also allows for the UI to be data-bound directly to the entity class if
appropriate (so no read/write property code).

If I am mistaken, and this /doesn't/ relate to such closely related
properties of an object, then any reasonable approach shold work... again,
/as long as/ the API is clearly named. For example, if it saves a customer
and an order, have SaveCustomerAndOrder() (with the 10 strongly-typed,
clearly-named parameters).

Marc

 

[Guest]

1) use parameters' array to send data to the function
http://msdn2.microsoft.com/en-US/library/w5zay9db(VS.80).aspx
2) Create and send object that keeps all you params

I recomend first case

Hi,
I'm trying to write a update method, in which when the user clicks the
update button the update method is passed 10 form fields. Then a update SQL
is run to update the database.
My question is whats the best way to pass large numbers of parameters into a
method. Ten seems a large number to be passing into and out of a method.

Stephen

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Marc Gravell]

IMO, it depends what we are doing here; if the 10 is actually something like
(for example) a user-defined list of strings(variable-size, identically
typed) then I agree 100% : "params string[] someParam" would be a good
choice. However, if the successive parameters are, in fact, different
things, then "params object[] data" is the *last* thing I would want to do;
you'd then need to remember that data[0] is the name (a string), data[1] is
the age, etc; it provides no type-safety, no "is everything provided"
safety, and provides no clue to the caller what they should be providing
(types, how many, or what they mean). In this case, "string name, int age,
(+another 8)" is much more supportable long term, as it addresses all of
these.

To me, at least. Put it this way: if somebody in my team did that to me,
then they'd be re-doing it before it gets anywhere near a server...

Marc

 

[Guest]

Certainly it's really depends on. But trying to guess by origin message " is
passed 10 form fields" we treat with one type params

We even could create and send XML, that is self-described, as param

IMO, it depends what we are doing here; if the 10 is actually something like
(for example) a user-defined list of strings(variable-size, identically
typed) then I agree 100% : "params string[] someParam" would be a good
choice. However, if the successive parameters are, in fact, different
things, then "params object[] data" is the *last* thing I would want to do;
you'd then need to remember that data[0] is the name (a string), data[1] is
the age, etc; it provides no type-safety, no "is everything provided"
safety, and provides no clue to the caller what they should be providing
(types, how many, or what they mean). In this case, "string name, int age,
(+another 8)" is much more supportable long term, as it addresses all of
these.

To me, at least. Put it this way: if somebody in my team did that to me,
then they'd be re-doing it before it gets anywhere near a server...

Marc

1) use parameters' array to send data to the function
http://msdn2.microsoft.com/en-US/library/w5zay9db(VS.80).aspx
2) Create and send object that keeps all you params

I recomend first case



--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do
not
cease to be insipid." (c) Friedrich Nietzsche

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche