Localizing BOs
Old forum URL: forums.lhotka.net/forums/t/2383.aspx
ajj3085 posted on Monday, February 19, 2007
Hi,
I'd like to start storing information such as date / time's in my database as UTC, mainly for the future that will need to display that information in the user's local date / time. I also am in the very near future going to be rolling out Notification Services, which expects most things to be in UTC.. so I'd like my datetime fields to use UTC for consistency there too.
On the BO side, users should work as they do now in their local time. Going to and from the database should be UTC.
Should the BO keep UTC internally and through the properties handle the translation from local to UTC? Should the BO work only in local time and let the DAL translate the values?
What is everyone else doing?
Thanks
Andy
SonOfPirate replied on Monday, February 19, 2007
The approach I have taken thus far is to try and be as consistent as possible when applying globalization/localization to my BO's. And since all of the string values that I use are managed in the base/default english language in my BO's and localized via resource files when displayed, I've leaned the same way when it comes to date/time properties. The date/time value is maintained in UTC and translation into the user's local time is analagous to retrieving a localized text string, imo.
HTH
ajj3085 replied on Monday, February 19, 2007
Pirate,
So where do you translate between UTC and local time? Do the BOs assume the DateTime / SmartDate is Local? Do you set the Kind property at all?
Thinking about it, I'm not sure doing the translation in the DAL is a good idea, because in a remoting environment I guess its possible that the server isn't running in the same culture as the client... unless I send the client culture.
Andy
SonOfPirate replied on Tuesday, February 20, 2007
I have the BO handle the translating when setting or getting the property. In other words, the private internal variable used within the BO to store the value is in UTC. Then, when the value is used by the client (via the get accessor), the client's culture is used to translate to local time. Likewise when the value is set. I believe this is consistent with how other aspects of localization are applied like resource strings plus puts the logic into the BO so the back-end database doesn't care what is being stored. This way the BO decides the format being persisted.
I've thought about implementing a config switch to indicate whether all dates are stored in local versus UTC but that would only be applicable if I did implement it in the DAL where it would be global to the whole application. I'm still considering this then I'd have a way to set it for the whole application or on a per-BO basis as I'm doing now. But, you raise a good point about passing the client culture into the DAL in order for this to work. So, for now, I think I will just continue using the same approach I've been using (above).
HTH
Fellmer Lloyd replied on Tuesday, February 20, 2007
Hi
Interesting thread!
SonOfAPirate, isn't it bad for the performance if the private DateTime is "calculated" on every property-get?
Yeah, it isn't a big operation, but imagine a DataGridView with a lot of data in it...
Fellmer
ajj3085 replied on Tuesday, February 20, 2007
Fellmer,
Yes, it does impact performance... but at the same time the calculation is simple addition or subtraction, something computers excel at!
![Smile [:)]](/emoticons/emotion-1.gif)
ajj3085 replied on Tuesday, February 20, 2007
Pirate,
Thanks for clarifying. This is the approach I was leaning toward.
My only concern is simply forgetting to do the translation.. this feels like something that should be encapsulated.. perhaps a SmartDateUTC class or some custom attribute scheme?
SonOfPirate replied on Tuesday, February 20, 2007
Andy,
You're one step ahead of me. After posting my last message, it occurred to me that the more appropriate place to centralize this logic would be within the date itself. I'm not sure if it should be a separate class or not, though.
Having it encapsulated would allow the use of a global "switch" such as what I mentioned unless it was a dedicated class, as you stated. Not sure cuz I have to consider the complexity of having yet another data type to work with since I deal with a team development environment with on-site, off-site and off-shore resources. As is, I had to rename SmartDate to simply DateTime so that it was more obvious that this was to be used in lieu of the System.DateTime type.
I was also thinking of some way to integrate the System.ComponentModel.LocalizableAttribute that already exists into the mix somehow. Since the purpose of this attribute is to mark a property as...well, localizable... I thought that it could be what triggers the translation at the DAL level. This would simplify the code by encapsulating the logic outside of the BO's while allowing the flexibility to determine which, if any, dates exhibit this behavior.
I agree completely that it would be totally undesirable to repeat the logic in each property that requires this behavior (which I am doing at the moment!). Question is where it is best to put the code...
ajj3085 replied on Tuesday, February 20, 2007
Pirate,
I'm not sure the LocalizableAttribute will help us here. I read up on it, and it seems to enable you to localize control properties to a resx automatically. For example, the Text property on a button. The framework will automatically pull the value from the appropriate resx file based on the current culture. Given that we don't want to store the dates into a resx, that path seems a dead end.
In your situation, you could probably just add the functionality to the DateTime class you now have and no one would be the wiser. I think a class which manages this is a good idea and then simply using that class everywhere to handle the translation.
I'm going to explore that option I think... i'm just going to add a UtcValue to the SmartDate class.
ajj3085 replied on Friday, February 23, 2007
Pirate,
Just wanted to update on my findings.
One of the things I had forgotten is that the DP attempts to keep a consistent context between server and client for the BO. The DP will actually properly set the CurrentCulture and CurrentUICulture on the thread before letting the BO continue.
Because I can rely on this, I'm thinking I'll have the UTC to local time conversions handled by my data access layer. Now, is that a valid thing to do, or should the BOs really be responsible for translating from local to UTC and back?
Suggestions?
Andy
JohnB replied on Saturday, January 19, 2008
I am in
the process of essentially implementing the same design with regards to UTC
handling. We're looking to store all dates in the database in UTC and have the
business objects convert the date to the user’s local time.
I was wondering if you guys had run into any issues creating reports with date filtering
where the dates were in UTC format? Crystal
reports or reporting services etc.
Thanks,
John
ajj3085 replied on Monday, January 21, 2008
John,
All of my reports are requested through the business layer as well; I have Csla objects which contain the report data, so my DAL ends up handling the date translation for me.
Andy
JohnB replied on Monday, January 21, 2008
Andy,
I can certainly see using Csla for
my report data but I was thinking that I would not be able to use it effectively as a data
source for my reporting solution. I have not worked with any of the reporting
tools to know if I will have any issues but I just thought that I might. May I
ask what type of reporting system you are using?
Regards,
JohnJoeFallon1 replied on Monday, January 21, 2008
I use Active Reports .Net with CSLA BOs and it works fine.
The only minor issue is that the data has to be pre-sorted. For some reason they did not build a Sort option into their report designer. Otherwise it is a fine product.
Joe
Copyright (c) Marimer LLC
