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".
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.
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.
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.
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.
Is it okay?
Yes. In some cornercases it might be.
Are there better ways?
In either case, have a look at