To provide this ease
of use, we encapsulate the Live Search web service searching inside of our control??™s code base.
We provide a public data-binding method to load up the control UI from the result set, but the
means to do it are abstracted away from the developer. All a developer needs to do is customize
the UI and let the control do the heavy lifting of communicating with Live Search and paging
the result set.
The first major architectural decision is to factor out the responsibilities of the control library.
Instead of one supercontrol, we factor the functionality into three major controls: Search, Result,
and Pager. We also have the ResultItem class, which contains the output templates as a utility
control in support of the Result server control. The diagram in Figure 12-5 shows the breakdown
of responsibilities.
The Search control has the primary responsibility of gathering input from the user and
setting up the Result control with the first page of results in a new search. We want to separate
Search from Result to allow flexible placement of the Search control??™s text boxes. The text boxes
can be deployed in separate locations on a web form so as not to constrain the web application
developer from a UI perspective.
Pages:
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782