1

I have created string to linq query library for internal company needs. We will use this library for querying over REST mainly, but it could be used in a lot of other different situations.

The gist of it is this, a user can create a query and put it in a url like this:

www.test.com/api/v1/users?query=$where[#eq(Name,Test)&&#gt(Id,12345)]$orderby[Name,-Id]

but they could also write something like this

www.test.com/api/v1/users?query=$where[#eq(Name,Test)&&#gt(Id,12345)]$last[]

$last[] returns a single object, while

$orderby[Name,-Id] returns a collection

In the library I have a method that will accept that string and accordingly will produce a collection or a single object, I am just not sure if that method should return a type of Object or dynamic.

Which is more suitable, which one's going to be less confusing for other devs?

Also, I'm thinking of releasing this lib as open source, but I don't know if there is a need for something like this to get released.

  • 2
    Why do you want to return object or dynamic? You could return a choice type or just an IEnumerable<User> with a flag to indicate if its a single result by-design. – CodesInChaos May 3 '16 at 13:44
  • I apologize but I don't think i understand what you wanted to say. I'm building expressions in runtime with Queryable and using a Provider property to call either CreateQuery for collections which returns an IQueryable or Execute for single objects which just returns an Object. I don't know if a user is going to request a collection or a single object, since they will combine queries however they want. Since i have only one method which will return either a collection or a single object i was wondering if the return type of that method should be a dynamic or an Object. – Nikola.Lukovic May 3 '16 at 13:59
  • 2
    If the result type can be one of two choices, a choice type is a natural way of modeling it. Or you could go the route of treating a single object as a collection of of item, possibly adding a flag to preserve the user's intention. – CodesInChaos May 3 '16 at 14:08
  • 1
    This is .. truly terrible. – DeadMG May 3 '16 at 17:12
  • @DeadMG Why? What am i doing wrong? Can you at least explain me in brief terms? – Nikola.Lukovic May 3 '16 at 19:17
3

Instead of "last", if you implemented "orderbyDesc" and "take" (and maybe also "skip") then your queries could always return collections, but users would understand that to get to the last item they would need to fetch it via $where[#eq(Name,Test)&&#gt(Id,12345)]$orderbyDesc[Name,-Id]$take[1]

I wouldn't change the collection to a single object just because of the final parameter, that feels unatural. In C#, the LINQ methods for skip and take still return collections, so I'd follow that pattern.

1

You should read up on the differences between object and dynamic. Here's some info https://stackoverflow.com/questions/5523031/dynamic-keyword-vs-object-data-type and https://blogs.msdn.microsoft.com/csharpfaq/2010/01/25/what-is-the-difference-between-dynamic-and-object-keywords/

The biggest difference is that the compiler leaves dyanmic checking to the runtime. So compiler errors become runtime exceptions. For instance, this throws a compiler error:

object abc = new object();
abc.BadCall(); //compiler error

But this compiles without any errors and will throw a RuntimeBinderException exception:

//VVVVV ----- only changed "object" to "dynamic"
dynamic abc = new object();
abc.BadCall(); //runtime exception here

You'd rather have a compiler error than a runtime exception if you had the choice. Here you do.


I can think of two uses for the dynamic keyword:

  1. You can use it to make Microsoft.Office.Interop.Excel calls more readable.
  2. You can use as a replacement to the Visitor design pattern.

If my only choice was between object and dynamic and I could use them interchangeably, I'd pick object.

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.