Mastering PowerBuilder

Service Oriented Class Libraries

In this methodology, all the functionality is encapsulated into reusable classes (called as service classes), typically, non-visual custom classes. When an object needs certain functionality, let the object request the service from the service class. For the sake of example, we have a DataWindow user object in which we want to provide all the required functionality.

In the traditional way what we would have done is, define the methods in the DataWindow user object itself. Then what happens at run-time?  At run-time it needs more resources. This is because the object is fat. The reason being that we have defined all potentially required methods in the object itself.

In the service-oriented methodology, what we are going to do is, define all functionality separately, one object for each functionality, i.e., one class for sorting, one for filtering, one for find & replace and so on. When the DataWindow needs a feature, say, sorting, it requests the service from the sort service. That means, we instantiate only those service classes that are required. In technical terms this is called delegation and in a consultant terminology it’s called outsourcing. In this example, DataWindow is delegating the work to different services. It’s something like a client/server model. The client (the DataWindow user object) requests server (service class) for the service. The server (service class) does the actual work that is requested by the client (the  DataWindow user object). In this methodology, we use events at the client (DataWindow user object) to route the requests to the appropriate service class. This approach has its own merits & de-merits. However the advantages over weigh the disadvantages.

Home	Previous Lesson: Nested General Purpose Classes Next Lesson: Disadvantages