Named Properties or the Get Method: Which Is Better?

Even though you can access the underlying attribute easily using the Get method, I recommend that you use the ADSI properties wherever possible. ADSI works hard to make life easier for developers. It performs data type conversions and always returns a variant value. Generally, ADSI properties can be used without conversion in other ADSI methods.

Another advantage of using named properties is that they always exist. The Get or GetEx method will throw an error if the attribute currently has no value. (See the "Handling Errors in ADSI" section earlier in the chapter for information about error handling.) The named properties, on the other hand, will always return something, or NULL if there is no value. However, in some cases, an interface may define a value that isn't supported by the current provider. This will result in an E_NOTIMPL (not implemented) error. The ADSI documentation contains a list of the supported interfaces and properties for the ADSI LDAP provider. (See the topic titled "Provider Support of ADSI Interfaces" in the ADSI documentation.)

There is a small performance hit incurred by using Get rather than a named property. When you call Get and pass the name of the attribute as a string, ADSI must look up that attribute, which takes some additional time. Of course, since not all LDAP attributes are mapped to ADSI properties, there are times when you must use the Get method. In case you need more encouragement, it makes sense to use the ADSI properties in regular practice just in case the underlying structure of Active Directory changes. ADSI will likely be updated to return the correct information regardless of which attribute contains it.

Accessing Properties in Yet Another Way

In Visual Basic and VBScript, you can access object properties without explicitly calling the Get method. For example, the following two lines of code are functionally identical:

 varClasses = objADs.GetEx("objectClass")
varClasses = objADs.objectClass

This may seem to contradict what I've been talking about, but it doesn't really. It's impossible to have a named property for every possible attribute because attributes can be added at any time by extending the Active Directory schema. However, as you saw, ADSI allows access to attributes using the Get method; what's new here is specifying the attribute name as a property, even though the interface, IADs in this case, doesn't have a named property labeled objectClass.

What ADSI does in this case is make an implicit call to the Get method, passing the property name, objectClass, as the attribute. This makes things convenient for developers, but it is costly for performance. Since Visual Basic does not recognize objectClass as a named property of the IADs interface, it must defer to the object implementation to figure out what to do. Specifically, Visual Basic and the scripting languages use the IDispatch interface to pass the property name to the object for handling.

The ADSI implementation of IDispatch allows for dynamic properties in addition to the properties defined for the various ADSI interfaces. However, using IDispatch causes Visual Basic to use late binding. This decreases performance because of calls to get the dispatch ID (DISPID) for the referenced property.

Because of the hoops that Visual Basic has to jump through, it's better to call the Get method directly, which saves Visual Basic a few steps. The performance penalty is probably negligible, particularly in light of the time required to retrieve information from the server, but to me that means it's even more important to save CPU cycles wherever possible.

The scripting languages always perform late binding, so it does not matter whether you use the Get method or not. For examples in this book, I'll use Get for properties not defined by the interfaces for consistency.



MicrosoftR WindowsR 2000 Active DirectoryT Programming
MicrosoftR WindowsR 2000 Active DirectoryT Programming
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 108

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net