The first thing that I would do is create a centralized shared class that accepts virtually any type of data that may need to be converted. This would be a shared class, so it would not need to be instantiated and would always be accessible.
Public Shared Function ConvertMeterToFeet(ByVal meters As Integer) As Single '-- Do some conversion stuff here End Function
End Class
You could then access this directly from within a BO if you had the need. So the first order of business would be to create your class that will be reusable and then access those shared methods within the BO when a conversion needs to take place.
I have wrestled with unit conversions my entire life (e.g. 1 Lego set = ??? Lego pieces, etc.). Now, I have been wrestling with the best way to handle these conversion within the SF framework. Would the BO be the best place to do this? My real world example is this: a salesperson enters a sales order for a part. The part is sold in meters; however, we are a non-metric manufacturing plant and must have everything in English standard units. So, a conversion must occur between the sales order and the work order for the production plant to make this part. The actual conversion is a piece of cake, but where would I put this thing? In the DB (done that)? In the BO (considering that)? Elsewhere (huh?)? The issue starts to become one of complexity. Once the number is calculated, then it is used in a lot of other places (reports, time-to-complete calculations, inventory levels, etc.).
Can anyone provide a tad bit of direction on this issue? Perhaps an overview of how you handle conversions?
Thanks!Bill