Programming Microsoft ASP.NET 4 - Dino Esposito [289]
A fundamental further step is required to enable the template to successfully process data-bound expressions. You must place a call to DataBind on the title item. Data-bound expressions, in fact, are evaluated only after a call to DataBind is made that involves the parent control that hosts the expression. Without the DataBind call, templates will work correctly but won’t display any <%# … %> expression.
Summary
ASP.NET provides a wealth of server controls from which you can likely choose exactly the control you are looking for. If this is not the case, and the control simply doesn’t exist, you can create your own control from the ground up or by extending an existing control, and obtain incredibly powerful results. Writing a control is a matter of defining an appropriate object model and providing an effective rendering algorithm. Aside from these two points, other equally important aspects of control development are containment, naming, and integration with the engine that supplies state management.
In this chapter, we’ve built a few ASP.NET controls with different capabilities, from simple components capable of rendering an HTML tree to controls with rich support for data binding and templates.
Part III. Design of the Application
In this part:
Chapter 13
Chapter 14
Chapter 15
Chapter 13. Principles of Software Design
There is nothing like returning to a place that remains unchanged to find the ways in which you yourself have altered.
—Nelson Mandela
Maintaining a software application is probably harder, and definitely more bothersome, than writing it from the ground up. A large part of a developer’s career is spent performing maintenance tasks on existing code rather than planning and writing new software. Armed with this knowledge, I usually advise developers and architects I work with to always give top priority to one specific attribute of the numerous possible attributes of a software system—that attribute is maintainability.
The biggest challenge that many software architects face today is how to design and implement an application that can meet all of the requirements for version 1 plus other requirements that show up afterward. Maintainability has been one of the fundamental attributes of software design since the first draft of the ISO/IEC 9126 paper, back in 1991. (The paper provides a formal description of software quality and breaks it down into a set of characteristics and subcharacteristics, one of which is maintainability. A PDF version of the paper can be obtained at http://www.iso.org.)
The mother of all challenges for today’s software architects is focusing on current requested features while designing the system in a way that keeps it flexible enough to support future changes and additions. In this regard, maintainability is king and you should favor it over everything else. Maintainability represents the best compromise you can get; with a high level of maintainability in your code, you can achieve anything else—including scalability, performance, and security.
That sounds very nice, but how do you write software that is easy to maintain?
There are a few basic principles of software design that if properly, and extensively, applied will transform a piece of code into a manageable and flexible piece of code. Doing this probably won’t be enough to save your team from having to fix a few bugs once the application has been deployed to production, but at least it will keep regression at a reasonable level. More importantly, these principles make it less likely that you’ll have to fix a bug with a workaround rather than with a definitive