Box Search Manager has a design flaw

[jdbaker]

To demonstrate this problem, try receiving the mdfilters as a json string instead of creating them as an anonymous object. Now turn the mdfilters json into an anonymous object using... what exactly? If newtonsoft then you have to create an instance of an object that has all the members you need. But which members do you need? Why, just look at the json of course!

There is a way to receive what is essentially a dynamic object without having to make a strongly typed one just to turn it back into a dynamic object? Seems like a json string would be ideal.

[mattwiller]

@jdbaker You're right — this interface doesn't seem ideal. I'm not sure that we want to go all the way to taking a JSON string as the parameter value either, but what if we extended the BoxMetadataFilterRequest class to include helper methods for constructing the correct filters? Would something like the following imaginary interface work for you?

using Box.V2.Models.Request;

var mdfilter = new BoxMetadataFilterRequest(scope="enterprise", templateKey="myMetadata");
mdfilter.equals("/field1", "value1");
mdfilter.lessThan("/field2", 100);

var mdfilters = new List<BoxMetadataFilterRequest>();
mdfilters.Add(mdfilter);

var results = await client.SearchManager.SearchAsync(mdfilters=mdfilters);

[jdbaker]

I want to avoid crafting the filter object twice: once when the controller receives the user input for their search, and then again when the API gateway sends the request to box via the sdk. It would be nice if there was a way to make it once and then serialize/deserialize it.

These helper methods look nicer than the anonymous object, and would save me having to write reflection. If they resulted in some strongly typed (and serialiazable/deserailizable) object, now we're cooking. Then I can craft my request once, and serialize/send in along to my API gateway without having to duplicate the code for making a filter.