| Components are objects that can be used over and over again in different applications. They usually characterize a real-world object. Let's go back to the clock factory analogy from Day 3, "Using Visual Basic.NET and C#." To build a clock, you take a bunch of components, such as springs, hinges, glass, wood, and pendulums, and put them together. ASP.NET applications, as well as regular applications, are exactly the same they consist of bunches of parts that are assembled to build a cohesive whole. Imagine that the clocks you're building consist of one component each clock is one piece of wood. These clocks don't work very well the hands don't move, the pendulum doesn't swing, and so on. However, once you split the clock into separate pieces the second, minute, and hour hands; the pendulum; the face it's much easier to construct the clock and make it work flawlessly. Also, when you have many pieces, switching them out becomes easier. If the minute hand breaks, for instance, you can easily take it out and add a new one. Or if a more advanced pendulum is developed, you can simply upgrade the old one, saving both time and money. There is a counter argument to this, however. Having too many components defeats the purpose by introducing unnecessary complexity. Why would you need to divide the pendulum further? You're left with parts that work just as well in one piece. In terms of ASP.NET, components are pieces of reusable code that enhance your application or give it new functionality. The user controls that you developed on Day 5, "Beginning Web Forms." are components. Code-behind forms can be thought of as components. Even Web controls are components that you can plug into your pages. A component is used to describe a real object, such as a calendar or a book. In an ASP.NET page, a text box or a database result set would be considered a component. What Are Business Objects?  | Business objects are components that encapsulate code that's applicable to your application. Writing code that's used to provide non-UI functionality is known as business logic or business rules. Hence, components that implement business logic are known as business objects. |
For example, if you followed the last bonus project in "Week 2 in Review," all the code you developed for interacting with the database was business logic. It was the code that communicated between the UI and the database. Ideally, this logic should be separated from the ASP.NET pages into a business object. The ASP.NET page should only be used for UI purposes and processing that belongs on the client side of the application. A common example of a business object is found in an e-commerce site, which has to retrieve shipping charges from different shipping companies. A developer can build this logic into an ASP.NET page, but then it would be difficult to modify if shipping rate calculations change in the future (not to mention that it's not very reusable). A smart developer can then come along and create a shipping component that can be used by any ASP.NET application. This component retrieves information from shippers' databases and provides the e-commerce application with everything it needs. The component is reusable, and any changes can be made in one place without disrupting the ASP.NET pages. Why Use Components? You may have heard of the three-tiered application model, which divides applications into three (sometimes not very distinct) layers: a UI or presentation layer, a business logic/object layer, and the data layer. This model is a good one for developing Web applications, and it's not very difficult to implement. Figure 15.1 illustrates this model. Figure 15.1. The three-tier model consists of UI, business logic, and data layers.
It's kind of like a theater production. The first layer is the performers on stage. They provide the "UI" for the audience, engaging their attention, giving them an experience, and so on. This is the level that the audience interacts with. The second level consists of the people who provide the direction and cues: the orchestra, the stagehands, cue directors, and so on. All these people interact with the stage performers but aren't seen directly by the audience. They provide direction and give material to the actors. Finally, the third level is the people responsible for the scenes and material: writers, artists, set designers, and so on. All of these people work together to provide the substance of the production. They're not seen by the audience except through what they produce. This model of putting on performances is very well defined and fine-tuned. Imagine if a single layer was missing. Without the performers, the production couldn't be put on. Without the writers and artists, there would be no show to perform. Without the middle layer of stagehands and such, the performers would have a difficult time doing their job and one of the other layers would have to take up the slack. The same model applies to developing Web applications. The absence of a layer makes the application that much more difficult to produce. In an e-commerce site, the first layer consists of the UI (forms, shopping cart, graphics, and so on). The middle business layer consists of logic to control pricing, shipping costs, and so on. The third layer, the data layer, consists of the inventory stored in a database. If any layer is missing, another layer must take up the slack. In more concrete terms, using business objects in a middle tier allows you to better separate and define your application. Your ASP.NET pages no longer have long, obtuse code that doesn't deal with UI. ASP.NET pages are used to provide a visual focus for the user, so why crowd any code that doesn't deal with UI into those pages? Granted, you've been doing just that for several days now. Functionality such as data access logic could be pushed into business objects in a middle tier. In many of the examples, though, the functionality was so simple that it wasn't necessary to introduce a third layer and the increased complexity that goes with it. Business objects are excellent for encapsulating non-UI logic, but you need to figure out whether or not an application is complex enough to warrant a third tier. Components also provide a more efficient mechanism for executing functionality. For instance, recall the calendar control from Day 5. With just a few lines of UI code, you can display a fully interactive calendar that's tailored to your design scheme. You don't have to worry about rendering the calendar, filling the weeks, figuring out the number of days in a month, and so on. All that is handled for you. Likewise, you should develop a component so that the people who use it don't need to worry about how things work behind the scenes. They can just use it. Even if the developers and users happen to be the same people (you, in this case), this still provides an easy mechanism for implementing functionality. Of course, don't forget the obvious benefits. The reuse of code is increased, making for a smaller and tighter application. Compiling code separately from ASP.NET pages improves performance. And maintenance is easier change the business logic once and it affects the whole application. Also, as part of the .NET Framework, any objects you create can be inherited from and extended if needed. Sometimes, though, the distinction between the layers isn't very apparent. Where exactly do you draw the line between UI functionality and business logic? This is a question that developers have been asking for quite some time. Today's examples will try to make the distinction as clear as possible, but sometimes it's a matter of judgment. How ASP.NET Uses Components ASP.NET uses the /bin directory, known as the assembly cache, for its compiled objects. After you develop your business objects later today, you'll compile them and place them in this directory. Any objects in /bin are automatically loaded by your ASP.NET application when it's started. This allows you to use the components you develop in your pages. You can also manually load objects that aren't in this directory into your pages through the web.config file, but that's beyond the scope of this book. In most cases, you'll have no reason not to place your objects in /bin. Once the objects are loaded, you use them in your pages just as you use built-in objects. For example, the System namespace and all its classes are compiled in a single object file, stored in the global assembly cache. When you use these in your pages, you can either import the System namespace or reference objects by their full names System.Integer, for instance. You can use objects in the same way, as you'll learn later today. |
