The language-neutral architecture of .NET has made the creation of class libraries a more useful proposition than ever before - classes written in one .NET language can be used from any other .NET language, without the need for any special considerations. With the language obstacle out of the way, the benefits of using class libraries in (ASP).NET development are broadly the same as the traditional benefits of using classes in single-language development. In this section, we'll enumerate those advantages, and give some suitably themed examples.
Simplified ProgrammingBy putting complex functionality into classes with well-defined programming interfaces, other programmers only have to worry about dealing with those interfaces. To see how this works, consider ADO.NET itself as an example. When we use ADO.NET with SQL Server or Access, we don't have to worry about the intricacies of the Tabular Data Stream or OLE DB. As Microsoft likes to say, "It just works." You can write your class libraries in the same way. For example, it's quite easy to have one class that manages the details of loading data into collections for processing, and another that performs some checking on any attempted changes to that data before they're written back to the database. Other programmers can then just call your methods for loading, validating, and saving the data, without having to know anything about database programming.
EncapsulationEncapsulation is the ability of a class to hide its internal data and methods, and to present a carefully designed interface to its users. In this way, only the parts of the class that you want to be accessible are accessible. For example, when we use the Fill() method of a data adapter, we're really asking for the computer to work its way through a result set and put the data into a DataTable object. But to do our job, we don't know or need to know exactly how it does that. As a further demonstration, imagine we have a class whose objects will represent individual employees. Such a class could include a GetTaxID() method that might look something like this:
GetTaxID(strEmployeeID As String) As String Given this definition, we would expect to provide a strEmployeeID variable as a string, and to get a string back - but we don't know anything else about how it works. There might be a database query, or a message could be sent off to a BizTalk server, but in the end we really don't care. Such processes are hidden from us by the class's programming interface. A further benefit of encapsulation is that it allows you to present a simple interface to a potentially difficult operation. For example, suppose that we've created an instance of the employee class that we've been talking about, and that it's important for users of this class to be able to get hold of the employee's name. If the employee class has a member field like this:
Private mGivenName As String Then we can expose it to the outside world using a property, like this:
Public Property GivenName As String Get Return mGivenName End Get Set(ByVal Value As String) If Value.Length > 0 Then mGivenName = Value Else Throw New ArgumentException("Given Name cannot be blank.") End If End Set End Property The property is a part of the public interface of the class, while the field, being private, is not. Using a property allows us fine control over programmatic access to the value - by not including a 'set' section, for example, we could have made this a read-only value. Also, the property allows us to perform validation when some other code attempts to change its value; this would not have been possible had we just used a public field. In general, taking advantage of encapsulation in the design of your classes provides the following benefits to you and other users of your class libraries:
ReuseClass libraries promote the reuse of code by allowing different applications with similar needs to reuse a common set of classes. Suppose, for example, that you have three applications that all need to access employee information - one for a phone directory, one for processing insurance claims, and one for tracking helpdesk requests. Each of these applications may need to access different information about the employee - phone number, hire date, or perhaps office location. If our employee class were to expose this information as part of its interface, then each application could use it, rather than having to create its own. A further advantage of reuse is that classes that get used a lot also tend to get tested a lot. Classes that are well tested mean a boost to the reliability of applications that use them, and represent a time saving for you when you come to test such an application.
Enhanced SustainabilitySustainability measures the degree to which a class or an application adapts to changes in its environment. These changes could be in the structure or sources of data that the class works with, or in how other classes or applications use it. Highly sustainable applications adapt to changes quickly and with a minimum of effort. Designing good classes can become something of a balancing act. You want to provide as much information and functionality as is appropriate, knowing that this will promote simplicity and reuse in many projects. However, it's very difficult to anticipate every possible use, so it's hard to know exactly what interfaces you should provide. A good way to cope with this is to expose your information as generically as possible, and then let the consumer transform it into what they need. For example, suppose that your employee class provides a method that returns the employee's name and phone number formatted into an HTML table row, ready for output in an online telephone directory. That's great for the phone directory application - all it has to do is call your method and display the results - but it's not so great if the application needs to send its output to a WAP-enabled mobile phone. If you're designing for maximum sustainability, your class shouldn't provide such a method as the only way to get the phone number. Rather, it should provide the information in a generic format (say, an XML document) and let the consumer transform that into the desired output form. |