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.
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.
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.
Hi
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
HTH
Simon
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...
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.
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.
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
/Bromden
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.
Copyright (c) Marimer LLC