PowerBuilder: Article

NVOs and NVCs

NVOs and NVCs

Adaptations...as software developers we thrive on adaptations. A large part of our present and future work is and will be simply morphing or adapting our previous efforts or the efforts of others before us.

Sometimes we need to reassemble pieces when an application needs maintenance and other times we bring pieces from our past and get to enjoy the creative thrill of new application development.

Many things in our environment constantly change. When PowerBuilder first came into being, many of the TLAs (three-letter acronyms) we constantly toss around today didn't even exist. While it's important to utilize good practices, it's even more important to reevaluate, improve, and refine the rules we live with everyday. When Sybase added the concept of a component to the world of PowerBuilder, it was logically placed in the realm of the nonvisual object (NVO). While components are unmistakably NVOs, they are a specific NVO subclass and invariably require special handling whenever they're used. In order to have meaningful conversation and clear usage practices regarding these nonvisual components, they must be distinguishable from the ancestor NVO - thus the idea of an NVC.

Nonvisual Component
NVCs should be viewed as separate mini applications. The scope of NVC functionality can be greater than a single application. Logic built into an NVC can be shared across multiple applications and utilized as part of a multiphased transaction, even transactions spanning multiple databases. When using an NVC, the execution of logic is transparent to the caller.

NVCs are a great way to share resources (see Figure 1); however, overuse can also cause problems. If a Web application uses a large number of NVCs, be sure the code is not doing intercomponent calls, such as checking for an empty string. To illustrate, if there's a form that's been submitted with 30 different fields, you don't want to make 30 separate calls to a component. In this case, if you're running clustered application servers, you could even be calling between different boxes. In this situation it would be better to use an NVO that's locally instantiated. Be sure the NVC calls are warranted.

Nonvisual Object
A nonvisual object is an object that exists entirely within a single application scope. NVO classes contain business rules that are frequently reused. NVOs will always be an extremely important tool for PowerBuilder developers. Their role is critical for making robust and adaptable applications, even mini applications. When creating an NVO, keep the class size down; this will help your performance. It will take less time to load the NVO into memory and use fewer resources while helping execute the rest of your scripts.

Good candidate scripts for NVOs will be utilitarian and widely reused bits of code that help you get basic tasks done, such as special string handling or date and time functionality. You'll also find that time-tested code that's not likely to change and that enforces your everyday business rules is a good choice.

If you have existing NVOs, why not use them inside the components you create? Say you have a few killer NVOs, the only problem is they pass DataStores; don't be disappointed because the CORBA interface won't allow you to pass DataStores. These existing NVOs make great helper or inner classes and will give your components that extra piece of functionality you need to make an awesome component.

The Differences Between NVCs and NVOs
To begin there are extra events found in NVCs, such as the activate and deactivate events, that add additional complexity not found in the NVO (see Table 1). These added events make NVCs more powerful and flexible.

Having activate and deactivate events implies NVCs are meant to be pooled in memory to save the overhead of creating and destroying an NVC at every use. Conversely, NVOs are usually destroyed; these single-use objects indicate that NVOs should only be allowed to take up resources when required. Keep in mind that the single use may include many method invocations, perhaps for a validation routine, but when the routine is finished with the NVO, it should no longer be kept around; the destructor will get called and the resources will be released.

Each object is used and called differently. NVCs use proxies and execute remotely to the caller, while NVOs are loaded into memory within the caller's scope and execute locally.

The preparations required to use each of the objects is quite different.

An NVO Create statement will pull into memory the definition of the NVO created. Depending on the nature of the NVO, this may be a significant use of resources and is likely something you don't want to leave hanging around in memory. Because you would have to call the init() for any subsequent uses, be sure it's ready for the caller. Sometimes it's required to pass in the NVO's parent or the transaction the NVO will participate in. NVOs will frequently require that you call one or more methods to set the NVO to a ready state for method execution.

NVCs require the caller to use a remote interface definition, a proxy, and a connection to the server, which returns an IOR pointer. This pointer generated by a transactionserver.createinstance() call is simply a string of instructions on where to send a remote call and how to package a call to the Object Request Broker (ORB).

NVCs are self-initializing; code placed in the activate and deactivate events should complete the required setup and cleanup for each use. If there are memory-intensive objects like DataStores, it's more efficient to place those in the activate and deactivate events. However, to ensure there are no large result sets hanging around in memory, call a reset on your DataStores.

NVOs only have constructor and destructor events. Frequently this will require an Initialization method to allow for the reuse of the object. Passing in a Parent object or a Transaction object adds extra steps to your code, important steps that you shouldn't miss, depending on how the object is designed.

Holding an instance of an NVC remote interface, a.k.a., an IOR pointer, will always be less costly from a resource point of view than holding the entire definition of an NVO.

NVOs require holding a PowerObject variable reference, and the library holding the NVO source must be held in memory.

NVOs are internal to PowerBuilder. Even though you may use a particular NVO in many places within an application, it's not meant for consumption outside of PowerBuilder.

NVCs can be published for the world at large using CORBA-compliant data types, which means you can't expose the same data types as the NVO.

An NVO's logic and rules can be reused, but a copy for each application that uses that logic can eat up a lot of resources. An NVC can share the same instance across multiple applications. Which one is better - sharing or the always-in memory cost - depends on your usage and needs.

While a component shares many attributes with a standard NVO, there are enough important differences when we discuss and use regular NVOs and NVCs in development that a distinction should be made. A service object is different from a service component. Why waste any time inferring by context how to handle the initialization, storage, and cleanup of a given object? Spend the time talking about the logic that should be involved.

If the points I attempted to make sound reasonable, whether or not you agree, keep it in mind for the next conversation about NVOs and NVOs or rather NVOs and NVCs.

Give the new distinction a whirl; I believe you will find it lends clarity and efficiency to your discussions.

More Stories By Jerry Neppl

Jerry Neppl, previously CEO of a small liquidation company, has been working for PowerTeam, Inc., in Minneapolis, for the past year and a half, having fun and getting
paid to play everyday.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.