1

I am creating a method in an ASP.Net Web App that will be called in a few places of my application and it creates a record in the database. When I started to look at the database model (which I have no control over) I realized there are 50 columns that have I have to insert data into. That means when I build this method it will have potentially 50 parameters to it. That seems like a huge amount, but since the data all comes from a user input field and then put into a database table it all seems kind of required.

Look at this got me to thinking, what is a better way to deal with so many parameters? I was thinking of creating a model with properties and filling the model then passing that around but that would not work as the model would sit in the WebUI application and can not be passed to the Business Logic application for dealing with validation, manipulation, etc. as defined by business rules.

Is it ok to have so many input parameters in this method (I am thinking not) and if not what is a good way of dealing with so much data? This is a C# ASP.Net MVC Web Application.

  • 2
    Your instinct is correct, you are better off encapsulating that much data in an object instead of juggling 50 parameters. However, I would recommend using the search function as there are other questions like this that might help (this might actually be a duplicate, but I do not have time to sift through the search results to find out for sure). – user22815 Mar 2 '17 at 19:21
2

The best function is one with no parameters and no side effects :). You always know exactly what it's going to do.

Functions with fewer parameters are easier to reason about, so you're on the right track. Will the database model ever change? If it did you have to not only change the function but every invocation of the function.

You're idea of passing a aggregate piece of data containing all the fields is the right idea. Better yet, create additional functions that initialize and set that data for you.

Otherwise you could also just create a single function for every field, but that would end up in more database accesses.

1

Having a method with 50 parameters would be painful to maintain. So, use an object. That way your method signature stays the same if you need to add new properties to the object. The object or model can be passed to from layer to layer (cross cutting) or each layer can transform it as needed. UI Model => Business Model => Data Access Model.

Also, the big model can be split into smaller units. Are all 50 fields on one page and need to be updated at once? Or can it be done in smaller chunks? These are some items to consider when modeling the database structure to a business or UI one.

0

If you are dealing with form data, as it appears you are, I'd be tempted to use JSON and then serialise/serialise as needed.

0

When I started to look at the database model (which I have no control over) I realized there are 50 columns that have I have to insert data into

My first reaction would be to speak up against the model used; but that doesn't help, since you already said, you have no control (or aren't in charge).

You now have to deal with it.

Is it ok to have so many input parameters in this method (I am thinking not) and if not what is a good way of dealing with so much data?

Whether something is »Okay« is up to you.

In some cases it could be "acceptable".

Pro

suppose you have Good Variable Names

You read and write code dealing with this object less often than business logic. Chances are higher that validation rules change than columns. So: the "ugliness" is limited to a very minimum. Hopefully: write once and never look again in this corner of your code base.

Rule of thumb: If you more than once ask yourself »WTF?! Who came up with this?!«, you should have a look to the next section.

Contra

Even with Good Variable Names™ (constructor) methods with many ( a subjective measure, which starts in my case at 3 ) parameters involve the problem of knowing how the parameter order was exactly.

Agreed: There are 2 helpful inventions in the last two decades, being 1) modern IDE guide you along the path and 2) most languages now have named parameters.

But even that problem aside (C# has at least since 2010 named parameters and Visual Studio is a very good example of an IDE), there remain two problems:

a) do you have to understand what is going on there?

In case of a simple form, where you only have some basic checks like »is the postal code valid?« or something like that, you could use some standard Validators from your framework you use. If it is a write once and hopefully forget for a long time object, deeper understanding is not needed.

But if you have to have a detailed understanding, you should break the objects content along semantically appropriate lines. Meaning: Say you have a long document, break it into sections with Good Class Names™ and refactor your code to only take these "sections" as parameters (btw. section1, section2 are not Good Variable Names™).

If you had an Entity representing a document with 50 fields, you could break it down to perhaps 5 sections with 10 fields.

Your method now takes 5 instead of 50 parameters

b) the problem of typing

even if you deal occasionaly with such a method, you have to type stuff over and over again, which is annoying.

That leads to the next section.

Neutral

Independend of the question, whether it is acceptable or not to have such "fat objects" and such "wide methods", you should have a look at automating the job, aka reflection.

Say you have one object representing the Form and one representing the Entity, reflection makes your job easier to put information from the former to the latter.


tl;dr

Is it okay? Yes. In some cornercases it might be.

Are there better ways? Yes.

In either case, have a look at reflection.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.