# Automatic Databinding of controls to Model [closed]

I have developed a prototype framework (MVVM) where control on the form is bound to a model property using a naming convention and its UI behavior is controlled using custom attributes.

1. As of now the control name is divided into two parts - 3 part prefix and then the Name of the property in model to bind to.

For eg txtFirstName textbox is bound to FirstName in model. During construction/load, all controls are looped through -

BaseEdit baseEdit = (BaseEdit) control;
baseEdit.Name.Remove(0, 3),
true, DataSourceUpdateMode.OnPropertyChanged);


There are some other attributes such as [ReadOnly], [Unbound] which are used to control the UI behavior.

baseEdit.Properties.ReadOnly = Util.GetReadOnlyAttributeValue(
control.Name.Remove(0, 3), viewModel.GetType());


I am thinking of doing the looping the other way around, ie the Model properties, using a Bound attribute. Bound[ControlName, PropertyName]

Bound["txtFirstName", "EditValue"]
FirstName

2. All the dropdown type controls, combobox, dropdown, checkeddropdown etc are autofilled by using a 'Key' from their tag property.

if (control.GetType() == typeof(LookUpEdit) &&
!string.IsNullOrEmpty(Convert.ToString(control.Tag))) //Exact match
{
LookUpEdit lookUpEdit = (LookUpEdit)control;
DataBinding.InitializeLookUpEdit(lookUpEdit, lookUpEdit.Tag.ToString());
}


I took the biggest data-entry form with around 45 controls and tested the framework.

Is the above approach suitable for a big project? Any suggestions for improving the framework?

## closed as off-topic by Jamal♦Feb 21 '14 at 17:34

If this question can be reworded to fit the rules in the help center, please edit the question.

• Do you have a sample project so that it can be tested? – surfmuggle May 16 '13 at 9:55
• This question appears to be off-topic because it is about an architectural review as opposed to a code review. – Jamal Feb 21 '14 at 17:34

IMHO Anything that relies on controls' Tag property is fishy. In 15 years of VB4-5-6/VBA and then WinForms development, every single time I saw the Tag property assigned, there was a better way to solve the problem. I think using that property more often than not violates the principle of least surprise (POLS), because it's not typical to put anything in there - if anything it means a control is begging to be derived from that control's class, and featured with the relevant properties - which is obviously too much trouble to be worth the while.
That's my rant against using the Tag property. That said it looks rather clean, much cleaner than this similar question, but it suffers from the same issue: