views:

24

answers:

2

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.

+1  A: 

I vote for always the DAL. Relying on dates and times from layers beyond the database has been a source of bugs for me in the past. In most setups, you're more than likely guaranteed a consistent date and time out of your database. Time synchronization issues client - server and even server - server have resulted in nasty, hard to duplicate, hard to fix problems.

marr75
A: 

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.

p.campbell
I agree with your thinking - but surely one of the reasons to put this responsibility into the BL is because you have rules you want to enforce - like not having nulls. Was a case where the BL didn't care but the database did?
Adrian K