When designing an application, it is worthwhile to carefully consider your DELETE strategy. SQL provides us with the power to delete a record from existence. However, doing such a destructive operation might not be the right approach. It could cause us a lot of pain later on. Additionally, there is much value to be gained from historical records and it also provides us with possible future opportunities.
Suppose we preserve deleted customer records. There might be opportunities to run email campaigns to get them to come back.
Soft delete strategy gives us the flexibility to preserve data that is deemed not useful today.
Entity Framework Core and other ORMs provides seams where we can cleanly tuck away this functionality through the use of Interceptors. Here is a small sample of how you might implement this:
This allows the framework to abstract away the soft delete functionality from your application logic. Developers can simply delete entities as they normally would and call SaveChanges without worrying about how the operation is handled under the covers. However, this magical abstraction does introduce the possibility of developer confusion and future bugs if they are unaware of its existence. An alternative approach to handle soft delete is to make it explicit by manually implementing it within your BaseRepository. This way the functionality is visible and part of the API signature.
Ultimately, just like all software design decisions, we must weigh the pros/cons of both approach for ourselves. Each application is different and each team is different. Deleting a database record demands our full attention and thoughtful analysis. It is better to take some time now than to spent countless hours trying to recover a deleted record.
Tenzin kabsang 