ParamBuilder question-- won't all the methods become overwhelming?

[Steve H]

In section 10.2 of the book, there's a parameter builder object that
substitutes for "magic string" based query parameters. I understand
the advantage of a strongly typed object like this, to aid in
refactoring. But won't the ParameterBuilder object get overwhelmed
with methods if it's being used for all query string parameters?

For example, if I'm in view XYZ and call the Param object defined in
your custom ViewPageBase class (pg 144, for those who want to follow
along) I'll see the Username method-- along with every other method
defined for every other query string parameter in the site, including
many that have nothing to do with the view I'm currently on. Could be
I'm not understanding how the Param object works, or maybe I'm
overstating the problem, but it seems the Param object will get
bloated pretty fast?

[Jimmy Bogard]

Yeah, it could get big.  We use that pattern when we have a lot of common parameters.  Another option is to use input models for GETs, just as you would POSTs for forms.

--
--------------------
Please feel free to comment on the progress of the book, the content, and the code samples.  All code and text is available on the book's GitHub site at http://github.com/jeffreypalermo/mvc2inaction.  We hope developing this book out in the open and with your feedback makes it a great book for the community.