Format measurements (imperial/metric)

Format measurements (imperial/metric)

Old forum URL:

Bromden posted on Tuesday, December 02, 2008

I need some guidance concerning an application that I am working on that enables the user to view and enter measurements in inches or centimeters depending on culture. Measurement data is always stored in metric. Today the conversion takes place in the presentation layer. The conversion is handled by simple functions that are applied before binding and before data is saved to the business object. I believe it’s correct to handle the conversion in the presentation layer but at the same time it screws up any type of smooth databinding. Has anyone else faced this issue and come up with a solution?  Any suggestion would be helpful.

rsbaker0 replied on Tuesday, December 02, 2008

Why not just implement a specific property for this purpose e.g. CultureSensitiveMeasurement?

Your property getter/setter could interpret the actual internal value based on the culture, and the presentation layer can just directly bind to this property.

SonOfPirate replied on Tuesday, December 02, 2008

Depending on how you have structured your application, this could be the best solution.  I recently developed an application with similar requirements (although we allowed the user to select the system rather than discerning it from the culture).  We following the MVP design pattern for our application.  Doing this allowed us to manage our business objects using a single, standard system (also metric).  The presentation components handled any conversion necessary.  This decouples the rigors of conversion from our BOs.

The other option, as suggested, would be to abstract the conversion within your BO's properties.  In this manner, the value retrieved would be in the appropriate units based on the culture much like a resource string will be localized.  The reason we did not go this route in our application was because it was calculation intensive.  To perform a calculation, we either had to access the private variables containing the raw values or deal with possible variations in the equations (such as constants that would be different in metric vs. standard/english units).  It seemed easier to make our business logic entirely metric and support standard units in the presentation layer.

Hope that helps.


simon_may replied on Wednesday, December 03, 2008


In my view the conversion is purely a UI concern as you say. I handle the Binding's Parse and Format events and perform the conversions there. This does not interupt the the Binding mechanism and works well. Mind you, there is additional work to set this up in the UI. I am using winforms not webforms



rsbaker0 replied on Wednesday, December 03, 2008

You can do this in the presentation layer, but that means it has to be redone in every UI you support. You'll need separate implementations for WinForms, WPF, ASP.NET, etc.

If you encapsulate the conversion in a single implemented property, then you get all the supported UI's for "free".

Just my $0.02...

SonOfPirate replied on Wednesday, December 03, 2008

Actually, the intent of the MVP pattern is so that the SAME presenter is used for ANY UI.  By handling the conversion in the presenter, whatever UI you slap onto the app will display the desired units.


simon_may replied on Thursday, December 04, 2008

My primary reason for for placing conversion  in the presentation layer is that the UI is different for each measurement system. Imperial is not a decimal system and is best presented  with two seperate imputs for each value. For example, pounds and ounces, feet and inches. Thus the work has to be done in the UI regardless of any convenient property on the business object.

I take SonOfPirate's point but creating a presenter that will coexist with the different data bindings is a challenge.

Bromden replied on Thursday, December 04, 2008

Thanks for all the input. I must say that I also like the MVP pattern, mostly from a test perspective. I have at times been doubtful towards test driven development mainly because you end up creating a lot of test code which also needs to be maintained and in the end you only test half of the application (service layer down). With MVP patterns in place that really changes things.

My dilemma this time is that the application is already in place and I will have a hard time arguing the introduction of the MVP pattern since it will probably take a fair amount of time. But we have all been there :-)

Staying Alive



rsbaker0 replied on Friday, December 05, 2008

There is a hybrid approach of sorts.

Your BO could simply expose both an InchesMeasurement and CentimetersMeasurement property, and the UI could reconfigure itself based on the culture (e.g. have both controls on the screen, hide the one not being used, etc).

Purists might cringe at such a suggestion, but if your case is limited to a few instances of this, it might not be so bad. It still avoids doing the conversion in the presentation layer.

ajj3085 replied on Friday, December 05, 2008

Maybe I missed it, but has anyone suggested a new value type class that "knows" the units and proper conversion?  I'd think you'd use it in a similar manner to SmartDate.  Don't directly expose it in the UI, but maybe a string UnitAmount and UnitType property which affects the stored SmartUnit type?

Bromden replied on Friday, December 05, 2008

In that case I like your first suggestion better mainly because it concentrates everything to the property. In this scenario both the business object and the presentation layer has to get involved. Eventhough the presentation layer has minor imvolment (you can probably bind the visible property in  a lot of cases). In some cases though, it can become somewhat complex with the hiding and showing of controls and for the GUI to present itself neatly.

Copyright (c) Marimer LLC