Declarative vs Programmatic: opinions
-
I have an ongoing debate with a co-worker about the merit of using server controls or code-behind for data, and I thought I'd post here for other people's opinions. I use SqlDataSources bound to controls, whereas he puts labels on the page and does everything in the code. (Oh, and I use stored procedures and not text commands, which I feel suffices for a DAL in small apps, so let's skip that argument.) I like it because it seems cleaner, faster, more concise, and gives access to the control events so work can be done at the appropriate time. Which do you prefer and why?
-
I have an ongoing debate with a co-worker about the merit of using server controls or code-behind for data, and I thought I'd post here for other people's opinions. I use SqlDataSources bound to controls, whereas he puts labels on the page and does everything in the code. (Oh, and I use stored procedures and not text commands, which I feel suffices for a DAL in small apps, so let's skip that argument.) I like it because it seems cleaner, faster, more concise, and gives access to the control events so work can be done at the appropriate time. Which do you prefer and why?
Using controls such as SqlDataSource is faster in some respects, however, it does not suffice as a true DAL, not even with stored procs. (Its an argument you will loose 9 out of 10 time). This method binds the presentation to data much too strongly for me. You should be able to build the application so each layer is independent. I would say you are both right to a certain extent. The co-worker who is building everything by hand is going too far. DataBinding and templates can be used quite effectively. Separating the presentation and data, such as in a MVC or MVVM pattern gives much more flexibility and code reuse.
I know the language. I've read a book. - _Madmatt
-
Using controls such as SqlDataSource is faster in some respects, however, it does not suffice as a true DAL, not even with stored procs. (Its an argument you will loose 9 out of 10 time). This method binds the presentation to data much too strongly for me. You should be able to build the application so each layer is independent. I would say you are both right to a certain extent. The co-worker who is building everything by hand is going too far. DataBinding and templates can be used quite effectively. Separating the presentation and data, such as in a MVC or MVVM pattern gives much more flexibility and code reuse.
I know the language. I've read a book. - _Madmatt
Good answer @mark.
-
I have an ongoing debate with a co-worker about the merit of using server controls or code-behind for data, and I thought I'd post here for other people's opinions. I use SqlDataSources bound to controls, whereas he puts labels on the page and does everything in the code. (Oh, and I use stored procedures and not text commands, which I feel suffices for a DAL in small apps, so let's skip that argument.) I like it because it seems cleaner, faster, more concise, and gives access to the control events so work can be done at the appropriate time. Which do you prefer and why?
Are this labels put on the form only once at the beggining of the page "lifecycle"? If yes - then declarative way would be better for traffic. Because each change of the page, which occurs in OnLoad() method is added to ViewState and travels to client with html page. If labels will be defined in .aspx then they will be created on Init() step and there will no additional ViewState data