Question

Folks,
In a layered .Net solution that we have recently deployed, we now realise we need to cater for a certain business object to be in an unconfirmed/confirmed state. A certain category of system user should now be able to create this business entity in an unconfirmed state. The entity should be invisible to the existing system and repositories etc until it is set to confirmed.
The business object is used throughout the solution in lookups and other functions. The underlying SQL table that stores the entity is referenced in report stored procedures and views etc.
Can anyone suggest how best to incorporate such a change? Options could include adding a binary flag to the class/table or possible storing the new unconfirmed instances in a seperate table and moving into the “live” table once confirmed.

Answer 1

I would store this in a separate table, for a few reasons:

1. The unconfirmed items have different business rules, so they should be treated as a separate concept in your domain.
2. If you were to need another state, the binary flag approach would not scale, whereas the separate table approach would.
3. Retrofitting your application’s lookups and other functions to check for the unconfirmed/confirmed state would be tedious and prone to error.