Document OrderIdComponents etc rationale

[nickevansuk]

Question: Should OrderidComponents (and probably SellerIdcomponents too...) should be generic in TId instead of having OrderIdLong and OrderIdString properties on it?

Answer: the issue we found previously was that using that was it requires binding TId in the classes that use it, and given it’s used in so many places that ends up requiring quite a bit of wiring up - similar to how complex TBookableIdComponents / IBookableIdComponents is. So I think it’s one of those things that’s a combinatorial explosion of complexity when you get into it

If it was possible to just reference OrderIdComponents<> everywhere (i.e. unbound generics) then would be easy, though I didn’t think that was possible last time I checked… which means you end up creating an IOrderIdComponents interface to use everywhere instead and converting between them

Further investigation: If e.g. {OrderItemIdString} is used in the UriTemplate, when the implementer meant to use {OrderItemIdLong}, this can cause some harder to debug errors. Is it possible to apply some validation to ensure that OrderItdComponents is only used in one of the 3 modes within a particular implementation - perhaps by adding validation logic to the IdTemplate parsing, or use generics in some other way to achieve a configurable yet strongly typed approach.

As a basic example, it could throw an exception if e.g. a value is present in OrderItemIdLong, and an attempt is made to read OrderItemIdString, an exception could be thrown "this is not the value you are looking for".