AutoMapper a viable alternative to two way databinding using a FormView?

I've started using the FormView control to enable two way databinding in asp.net webforms. I liked that it saved me the trouble of writing loadForm and unloadForm routines on every page. So it seemed to work nicely at the start when I was just using textboxes everywhere....but when it came time to start converting some t开发者_如何学运维o DropDownLists, all hell broke lose. For example, see: Not possible to load DropDownList on FormView from code behind? ....and I had many additional problems after that.

So I happened upon an article on AutoMapper, which I know very little about yet, but from the sounds of it, this might be a viable alternative to two-way databinding a form to an domain entity object? From what I understand, AutoMapper basically operates on naming convention, so, it will look for matched names properties(?) on the source and destination objects.

So, basically, I have all my domain entities (ie: Person) with properties (FirstName, LastName, Address, etc)....what I would like to be able to do is declare my asp controls (textboxes, dropdownlists, etc) with those exact same names, and have automapper do the loading and unloading.

So if this worked, a person could just get rid of the cursed FormView control entirely, and it would be just one line of for binding and unbinding a webform.

(Yes, of course if I was using MVC I wouldn't have these problems, I know).

Caveat 1: AutoMapper would have to know the proper property name for each control type (the control itself would have the same ID as the property on the entity, but the behavior would depend on the control type), ie:

Person.FirstName --> form.FirstName..Text

Person.Country --> form.Country.SelectedValue

Person.IsVerified --> form.IsVerified.Checked

....so it would have to have the smarts to find the control on the form, determine its type, and then load/unload between the domain object and the webform control into the proper property of the control.

Caveat 2: Nested Controls - to complicate matters further, if one could pass a webform to AutoMapper (I don't yet know if you can), the source/destination controls are not necessarily in the root of the webform, so one would have to be able to perform a recursive search of all child controls on the passed webform (this is easy), returning a collection of all valid UI element type instances.

Caveat 3: User control UI elements are not public - when traversing the nested control hierarchy in #2, if you are using user controls, which do not expose their contained elements publicly (without hardcoding it so), one would have to do a FindControl for each element in the current AutoMapper collection. This one seems like a potential dealbreaker....

a) performance could be really bad (although if a User Control was found, it could be passed to the back of the queue and only processed if necessary)

b) from within an individual map function, how does one get reference to all the siblings of the current mapped element, in the current mapping function?

Any ideas??

Update

From what I've read, this seems like the path one would likely have to go down:

http://automapper.codeplex.com/wikipage?title=Custom%20Type%20Converters&referringTitle=Home

http://msdn.microsoft.com/en-us/library/ayybcxe5%28VS.71%29.aspx

---

I think your best long term solution would be to check out WebForms MVP - it provides a better abstraction layer over WebForms if you can't switch to an MVC environment. You would then have a much easier time mapping, as well as get the benefits of the MVP pattern.