Edition 0 Updated to asp. Net core 0

return
await connection.
QueryAsync
( 
@
"SELECT o.[Id] as ordernumber,
o.[OrderDate] 
as
[date],os.[Name] 
as
[status], 
SUM
(oi.
units
*oi.
unitprice
) 
as
total 
FROM [ordering].[Orders] o 
LEFT JOIN[ordering].[orderitems] oi ON o.
Id
= oi.
orderid

---

191 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
LEFT JOIN[ordering].[orderstatus] os on o.
OrderStatusId
= os.
Id
GROUP BY o.[Id], o.[OrderDate], os.[Name]
");
} 
} 
} 
The important point is that by using a dynamic type, the returned collection of data is dynamically 
assembled as the ViewModel. 
Pros:
This approach reduces the need to modify static ViewModel classes whenever you update the 
SQL sentence of a query, making this design approach agile when coding, straightforward, and quick 
to evolve in regard to future changes. 
Cons:
In the long term, dynamic types can negatively impact the clarity and the compatibility of a 
service with client apps. In addition, middleware software like Swashbuckle cannot provide the same 
level of documentation on returned types if using dynamic types. 
ViewModel as predefined DTO classes 
Pros
: Having static, predefined ViewModel classes, like “contracts” based on explicit DTO classes, is 
definitely better for public APIs but also for long-term microservices, even if they are only used by the 
same application. 
If you want to specify response types for Swagger, you need to use explicit DTO classes as the return 
type. Therefore, predefined DTO classes allow you to offer richer information from Swagger. That 
improves the API documentation and compatibility when consuming an API. 
Cons
: As mentioned earlier, when updating the code, it takes some more steps to update the DTO 
classes. 
Tip based on our experience
: In the queries implemented at the Ordering microservice in 
eShopOnContainers, we started developing by using dynamic ViewModels as it was straightforward 
and agile on the early development stages. But, once the development was stabilized, we chose to 
refactor the APIs and use static or pre-defined DTOs for the ViewModels, because it is clearer for the 
microservice’s consumers to know explicit DTO types, used as “contracts”.
In the following example, you can see how the query is returning data by using an explicit ViewModel 
DTO class: the OrderSummary class.