0

I'm struggling with logic that is duplicated in the front end code and the database. Right now, I just put a comment.

Here is a small example (the current system has a lot of much more complicated formulas).

In the front end, I have a single property that everything use to see the result.

Class CartItem

    ' The same formula is found in the database view V_CART_ITEM
    Public Readonly Property Cost As Decimal
        Get
            Return Price * Amount
        End Get
    End Property

End Class

In the database, I have a view that all queries and report use.

CREATE OR REPLACE VIEW V_CART_ITEM AS
-- The cost formula is also found in the class CartItem
select cart_item_id, price * amount as cost
from cart_item;

I think it's not to bad since the formula is only duplicated once in the whole system and a new developer would know what to do if there are any changes to be made. I'm wondering if there's a better way.

  • why do you have the view at all? – Ewan Feb 4 at 16:07
  • @Ewan there are multiple report/query that need the formula. Duplicating the formula cause problem in the past when one person would only update the formula at one place. – the_lotus Feb 4 at 16:12
  • Database is IO device, do not put business logic in there. Since it simple computation,, you can do it in the "front-end" – Fabio Feb 4 at 20:51
1

It would be better to only have this logic in the object.

You should protect your database with an API layer and have all queries/reports go through the API.

In the API layer you can use your object, thus ensuring that the Cost field will always be populated correctly

1

Always have one definition for your business rules.

That is a good rule, in practice though things get muddier. Particularly if you have multiple front-ends that do not agree on any form of shared implementation, or any shared implementation would be to brittle/slow/complicated to use. Even if you do manage to get all of the business rules into a shared medium, you still have the problem of keeping each of the applications/databases/etc... using the same logic - despite our sincerest efforts deployments are not instantaneous.

So how do you get around that? Tests and Versioning

Ironically you can write tests that check the UI/API/Database/Extracts/Reports and use the same Logic to check that the result appears to have been calculated by the same rules. To improve maters take a two prong approach:

  • pick specific values and predetermine their output values. Use the input values to test both the Test Logic, and the Application Logic. This establishes a minimal baseline.
  • randomly fuzz inputs using the logic in the test engine to determine the expectation, and compare that against the reality - report inconsistencies. This explores the unknown space and lets you determine where the Test and Application Logic diverge. The Fix is a decision as to who is right, consider taking those values and casting them as a specific test.

Secondly because there will likely be a time when parts of the system are out of sync as to what constitutes Business Rules, tag the protocols and objects in use with a version. At the very least do not operate on objects which do not match the version of the logic. If your code is smarter it might up-cast the object to the new version, or alternately fall-back to the older logic.

0

The complicated formulas constitute business logic. It depends from team to team on where they keep their business logic. A team with developers fluent in backend, would prefer to store business logic in SQL while a proficient full-stack team would be more comfortable with business logic in the API.

I prefer to keep straightforward business logic in the API like most developers reserving SQL SP's and Views for very complicated business logic to make use of database optimizations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.