Best practice for method parameters

currently, in my team, we have very live debate about some issues in our asp.net mvc project. to cut a long story short, it's all about should we be using objects as a some kind of container for parameters to call a methods in our pro开发者_如何学Goject...other side(me :)) is more on the side that methods should be called with primitive parameters...

what do you think and what is for you the best approach, and in which cases?

thank you :)

Yes, models/objects should be passed to methods. It's how the framework was intended to be used - hence the built-in model binder.

The approach of passing objects as parameters also allows you to refactor and change the details of your implementation without having to alter the method signature throughout your code if say, you wanted to include a new item of data in your method call, you could simply add a new property to your model object, rather than alter method signatures. It's a much more flexible and easier to read approach.

In contrast, I'm sure you will have seen method signatures in 'legacy' codebases that get really out of hand in projects of any significant age where developers keep adding parameters as they need them, rather than use an object (not my code, I should add, lest my reputation be ruined!) - This kind of thing can get quickly out of hand when code is being rapidly developed and can lead to code rot.

Finally, on a more general note about method parameters, if you start to have more than say 4, or 5, then this is usually an indication that your method is doing too much and needs to be refactored with respect to SOC (Separation of Concerns).

For simple operations, like Add() you would of course provide two primitive numbers, not an AdditionParameters object. However for a SetupCustomerEnvironment() method or something, you could imagine one or more objects be used to describe how the environment would look.

I like to distinguish parameters which actually "interact" with the method name, as if you are talking (Add() the number number1 to number2) to parameters that change the behavior of methods. If there were multiple ways to Add() number1 to number2, you could supply an AdditionBehavior object that explains for instance what to do if the result exceeds the data type used (overflow).

If you are using MVC (Model-View-Controller), then I would say usually it would be best to call methods with objects (or models). This conforms with the point of using MVC. If you have models with a large number of parameters, method signatures can become very long. Also, other programmers who might use your code will be able to abstract it better.

I strongly recommend using objects for your parameters. That's true MVVM and would provide not only provide you with abstraction but also containment. In my projects all my Domain Models are mapped to View Models which are to be used in views but with only the information required. Those view models are passed between views and controllers. This gives a clear impression that what is required in the View and whenever anything is to be added/removed you don't go about changing controller signatures rather simple modifications in a View Model class.

Also there is a case when you are using heavy Javascript at the client side. So copying your View variables one by one in a Javascript variables doesn't sound like a good strategy. You could simply JSONinify your whole ViewModel and it'll be available at client-side. This is very important when you are using something like KnockoutJS or BackboneJS.

As a rule of thumb, if you have a method accepting more than five parameters then it should normally be an object.

If we're speaking strictly about MVC action methods then I'd reduce this to one parameter in limited cases (where the other benefits of view models like validation and metadata aren't needed).