Skip to main content
3 of 3
added 34 characters in body
radarbob
  • 5.8k
  • 20
  • 32

calculate the "still to do actions" in real-time (i.e. every time the user opens the page)

Yes

Or would it be better to keep every action in the database

This is not mutually exclusive to the above; unless maybe "keep" means something else?

and keep this in sync with the CRUD operations done on each entity

You lost me


Update dynamic state every time any dependent state changes.

A business model - a OO class design - does this.

  • Observer Pattern (event handling): UI changes update the business model and the model calculates state. The UI is refreshed.
  • The database merely keeps the business model data. Design the data store update triggering any way you want.
  • The business model calculates state before it updates the UI or the database. Initial population vs active user changes? Irrelevant.
    • UI --> BM calculate state --> UI
    • UI --> BM calculate state --> Data Store
    • Data Store --> BM calculate state --> UI

Separation of Concerns

We all violate this all the time. Like Capitalize a name directly in a textbox. That's ok if the business model has that rule also.

Putting rules in the database is more hazardous. Like populating a new form with all zeros. Then the customer says "I want forms X, Y, Z to be blank, not zero. Had to write a new, virtually identical stored procedure just for those. But the new rule was in the BM you say? Does not matter. Blank fields are saved with zero. Now, is that a zero-zero or a blank-zero?

radarbob
  • 5.8k
  • 20
  • 32