[Question] Do we have a reason to use dynamics type in OrderQueries.cs file

[SychevIgor]

I just started working on #305 and got an interesting situation... I can't normally describe the return type for OrderController.GetOrder because type essentially dynamic.
after some research - I didn't find any reason for dynamic type here.
May I fix the type or could you explain the idea?

@CESARDELATORRE

[CESARDELATORRE]

@SychevIgor
The reason is that being dynamic, you can just change the SQL query (new attributes/columns, etc.) and you'll get that returned. you have like a dynamic ViewModel. No need to have static classes for those ViewModels. So, it is more agile when developing.
So, for a service used only by the same application, it is ok and more agile.

However, for a public API, it would be better to use ViewModels or "contracts".
And even for a long term application, I find that having explicit ViewModel classes is safer and also, as you mentioned, better for Swagger or even other "unknown clients".
So, after testing that PR well, we can merge it. But, can you test it with all the client apps? Including the SPA app and the Xamarin app?

Here's a longer explanation:
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/cqrs-microservice-reads
(Scroll down until you see the "Dynamic and static ViewModels" title).

As I said, that approach was very agile and flexible while developing, but once the app is stable and we think more in the long-term, I find that it might be safer to define explicit ViewModels (like DTOs) exposing explicit contracts.
Thoughts?

[CESARDELATORRE]

Closing this issue. We decided to accept the PR and use predefined ViewModel DTOs classes as it is better for public APIs but also for long term microservices, even if they are just used by the same application.
Also, as mentioned by SychevIgor, if you want to specify response types for swagger, you need to use explicit DTO classes as the return type. Therefore, predefined DTO classes allows you to offer a richer information from Swagger. That will benefit the API documentation and compatibility when consuming an API.