Sono in procinto di progettare un'API, una parte della quale implica la scrittura di POCO in un database.
In C #, abbiamo la struttura DateTime . Il valore "predefinito" per questo ( DateTime.MinValue ) è 01/01/0001.
Una parte dell'API serializza POCO nel database. Se un campo data è opzionale, dovrebbe veramente essere annullabile (nella sintassi C #, questo sarebbe definito come DateTime? ). Quello che vorrei evitare, è che i programmatori cadano nella trappola di scrivere DateTime.MinValue nel database a tutti . È una data valida, certo - ma odora di qualcosa. Quindi sto discutendo implementando una classe BestPracticeException che verrebbe generata in circostanze come questa.
Se l'utente dell'API ha davvero bisogno di gestire quella data, probabilmente dovrà anche occuparsi delle date precedenti e avrà bisogno di una struttura completamente diversa (ad esempio confrontando quanti mesi si sono verificati tra il 500 aC e oggi).
Pensi che impedire di scrivere 01/01/0001 nel database, nel complesso, sia una buona cosa da fare? Si potrebbe obiettare che è necessario distinguere tra l'assenza di data immessa e l'utente che non inserisce nulla. La mia risposta a che sarebbe che è la funzione di un processo di auditing più ampio che la raccoglierebbe, piuttosto che tentare di accertare l'intento da un campo che è nullo, o non nullo.