Automatic Databinding of controls to Model 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.


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.DataBindings.Add("EditValue", viewModelBindingSource,
                          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

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

if (control.GetType() == typeof(LookUpEdit) &amp;&amp; 
    !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?
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:

WinForms applications are better off with the Model-View-Presenter pattern.
[...] if you want to simulate WPF behavior in WinForms, the real thing will be much less trouble, and leave you with much cleaner code.
Sorry if that's not what you wanted to hear...

For a big project I'd seriously consider either MVP or MVVM with WPF.