Let's just say that the concept of namespaces is like an addressing system, similar to the Dewey decimal system used by libraries for categorizing, grouping, and locating books. It's really that simple.
As I've said before, .NET has tons of object classes ready for you to use to build applications. If I just provided a list of these, it would be longer than a football field and finding an object would be a pain in the posterior!
Imagine that you and I are standing outside your house in your backyard. We are enjoying a barbeque of succulent ribs and a few ice-cold beverages. You are slaving over the hot open barbeque and realize that you forgot to bring the tray of bacon-topped baked beans outside. You ask me to go inside and get them for you. Well, I've never been in your house before, because I came straight from the car to the backyard. (I know, I know!! Come on Peter, get to the point and stop talking about food again.)
"Where are the beans?" I ask.
"Go through the back door into the house, turn left into the kitchen. They are in the oven on the top rack," you say. These directions are easy enough to follow, and I successfully find the beans and return outside to our lovely barbeque.
"What does this have to do with namespaces?" you ask. I'll tell you in a way that's easy to understand. Your house could be looked at from the viewpoint of namespaces, and it would provide thorough directions to find baked beans in your house. The beans are in a namespace:
House.FirstFloor.Kitchen.Oven.TopRack
Your socks in a namespace:
House.SecondFloor.Bedroom.Dresser.TopDrawer
Aspirin, lawnmower, fine china, laundry detergent:
House.SecondFloor.Bathroom.MedicineCabinet House.FirstFloor.Garage House.FirstFloor.DiningRoom.ChinaCabinet House.FirstFloor.LaundryRoom.Shelf
Are you getting it? Namespaces are just like this in .NET. It is a system to describe where objects are stored. And let me tell you that it is a very logical system. We will be looking deeper into this in the next section of this chapter and investigating some of the namespaces we will commonly use when making ASP.NET applications.
When we created the Ball class earlier in the chapter, we included the Ball class code right in the top of the web page. Every time this page is called, that class is available for use by that page. This is the way we did it for the example, but it may not be the optimal way to achieve what you want.
You may want to create a component out of the Ball object. This is a fancy way of saying you will create the Ball as an object that will be available just as all the .NET objects are.
Describing how to create components is a bit out of the scope of this chapter, but I provide a teaser and some more detailed information on component creation in Appendix B. Right now, you're just investigating how to create a namespace. It isn't very different from creating an object. You must just call the correct keyword and follow the correct syntax.
Namespace Peter.Toybox Public Class Ball //Our Class Code End Class End Namespace
Namespace Peter.Toybox{ public class Ball { //Our Class Code } }
In the appendix you can see more about how the ball component is created, but for the next example let's imagine you've created your component and it's available for use in your application.
To use the Ball object in your application, you simply need to just let .NET know where the Ball object is, using its namespace, just like I could have found the baked beans in the oven by following its namespace directing.
Import Peter.Toybox
using Peter.Toybox
Notice that the keyword used by Visual Basic .NET and C# is different. Import is used to address a namespace in Visual Basic .NET and the word using is used in C#.
Top |