Date Created a specific example I’m interested in – but there are other bits of data that fall into the same category: data which you’d want to capture about any vaguely important entity.
Where best to do this: business logic (BL) or Data Access layer (DAL)?
Until now I’ve relied on SQL Server’s getdate() to populate the date created for me on insert into the table, but now I’m starting to wonder if I should be doing this more in the BL.
FYI – this has mainly been in web-based systems where you create an object in the BL (based on user input) and fire it off at the DAL – it’s not like I’ve been wanting to refer to the object in memory for ages (so having a “date created” property on the object for use in the BL on creation of the object hasn’t been an issue).
Perhaps there’s a third option – it occurs to me after reading Marr75’s answer that recording it twice might be useful in some senarios (once in both locations). You’d get the benefit of a consisent date/time in the data layer but you’d still have a BL driven value to refer to as well – I guess i’d depend on your use cases. This option isn’t without some risk, though – people might start using the wrong date for the wrong thing.
I’d say: yes.
Perhaps get into the habit of setting the created and lastaccessed dates in your BL. Then in your DAL, always be checking for nulls in those fields. If they’re null, consider your option: throwing an exception, or just filling in those values at that layer. Kind of a catch-all before insert/update.
I’ve had the same pattern as you describe in your question. I then was faced with having the application use/consume UTC timestamps, and I figured I’d just move that behaviour to the BL and/or DL classes. Yes, I could’ve used
GETUTCDATE(), but it just felt more appropriate to have this logic in the BL/DL.