One question bothers me when I see such code inside queries
SUM(oi.units*oi.unitprice) as total
Isn't it a part of business logic and we have duplication here? Yes, in this case it looks simple but imagine if it will invovle, for example, discount system.
To compare, the same in domain model: Order.cs
public decimal GetTotal()
{
return _orderItems.Sum(o => o.GetUnits() * o.GetUnitPrice());
}
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Hi @gmatv,
That wouldn't qualify as "business logic", it's just a simple math.
However, I do agree simple math can be not so simple, when you have to consider issues such as different tax rates per item.
A complex discount system would qualify as business logic
But then again, if that were the case, you would have to handle the complex calculation inside the Order and have it persisted, so you could use it in the query.
In this particular case we can't use GetTotal() in the query, because we are using CQRS and the query part is handled by Dapper, as plain SQL queries to the base tables and the order total is not persisted.
So, as usual, it depends on the context.
If you had to handle complex calculations AND were using CQRS with Dapper, you would have to calculate internally and persist the value.
If you where Using EF you could just call Order.GetTotal() although that could impose a heavy load on the system, or perhaps not, if you are handling a small number of orders anyway.
IMHO, in the context of this application, as a learning resource for microservices architecture, it's ok just the way it is.
I would even add that just because of the fact it raises this kind of dicusions.
Hope this helps.
should we close this as by design @mvelosop?
Hi @mairaw, yes it's ok to just close it, so doing it now!
Most helpful comment
Hi @gmatv,
That wouldn't qualify as "business logic", it's just a simple math.
However, I do agree simple math can be not so simple, when you have to consider issues such as different tax rates per item.
A complex discount system would qualify as business logic
But then again, if that were the case, you would have to handle the complex calculation inside the Order and have it persisted, so you could use it in the query.
In this particular case we can't use GetTotal() in the query, because we are using CQRS and the query part is handled by Dapper, as plain SQL queries to the base tables and the order total is not persisted.
So, as usual, it depends on the context.
If you had to handle complex calculations AND were using CQRS with Dapper, you would have to calculate internally and persist the value.
If you where Using EF you could just call Order.GetTotal() although that could impose a heavy load on the system, or perhaps not, if you are handling a small number of orders anyway.
IMHO, in the context of this application, as a learning resource for microservices architecture, it's ok just the way it is.
I would even add that just because of the fact it raises this kind of dicusions.
Hope this helps.