Pros and cons of declarative data binding in ASP.NET

While binding data to ASP.NET data aware controls like GridView and FormView, there is always two choices. Firstly you can do updating, inserting and deleting operations just in code behind. This way you should reference controls, get/set values and do actual operation in codebehind. Secondly it’s possible to do almost everything in markup of your aspx/ascx declaratively. This way you just tell ASP.NET that which method it should use and ASP.NET take cares of it for you. What of this ways is better? I’ve thought of about it and here is my findings:


1. Need less logic in code.
2. All logic is centralized in a single place in the place where data source or data web control is defined.
3. You are not forced to work with sophisticated API of data web control events and properties.
4. Development with this style is fast.
5. Suitable for small/medium projects and average ASP.NET developers.

1. Working with none primitive data types is a bit hard.
2. Their bug will not be detected unless in runtime instead of compile time. Because field and method names names are defined as embedded strings and will not be checked during compile.
3. Debugging is hard as you can not set a break point in declarative code.
4. Testing is a bit hard.
5. Declarative data binding turns your program a bit inflexible. Because web controls is placed in item template and edit templates so accessing them is not so easy. One example is when you want to add an ASP.NET AJAX ConfirmButton to a GridView CommandField. For this purposes you should use various events.

Scott Mitchel training series about data access in ASP.NET controls