Docs: Business logic inside queries

Created on 31 Jul 2018  Â·  3Comments  Â·  Source: dotnet/docs

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());
    }

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

guide - .NET Microservices Area - .NET Architecture Guide Area - .NET Guide

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.

All 3 comments

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

FrancescoBonizzi picture FrancescoBonizzi  Â·  3Comments

svick picture svick  Â·  3Comments

stjepan picture stjepan  Â·  3Comments

stanuku picture stanuku  Â·  3Comments

UweKeim picture UweKeim  Â·  3Comments