Component Development
As we developed our PerlNET applications in previous chapters, we put all the functionality in a single file. Such applications are referred to as monolithic. The technique of monolithic development is useful when we have to perform simple and focused tasks. We aim at writing short, effective, and readable code as much as possible. Obviously, when the requirements from our software grow, writing monolithic applications results in numerous lines of code, which leads to inefficient and unreadable programs. Besides, if our application resides on a network (probably inside some intranet) and it serves a large number of users, then we may reach an unpleasant situation of service denial. Thus, our goal is to develop scalable, robust applications that respond to growing demands of users, can serve large numbers of requests (in the case of implementing some kind of server), and perform a wide range of tasks according to predefined specifications.
The solution is to break our application into small, effectively working and integrable components. This way, we divide functionality between these components that will be used as bricks for constructing whole applications. We may use the same component as many times as we want (not beyond the memory limit) and compose our software from different components. In addition, we do not have to keep in memory all the components throughout the application life cycle—we can instantiate objects from the classes exposed by components, and the garbage collector will dispose these objects when we no longer need them. This is exactly the same scheme as with standard classes of .NET Framework that we discussed in Chapter 10.
The technique of dividing functionality into components is a part of object-oriented design (OOD), through which our applications will pass.
Components DefinitionWe define each component by a package (Perl Module), exactly as the classes are defined in Chapter 7, and in most of the cases each module contains one package. However, sometimes it is convenient to put several packages inside a single file to create a library of components. |
For each component, prior to its definition, we have to decide what PerlNET type it shall represent, and according to our decision, we will follow the rules of implementation for the chosen PerlNET type.
PerlNET TypesAs we stated in Chapter 1, a type in .NET is analogous to a class. PerlNET types (the class packages that we will develop in PerlNET) may be divided into Pure Perl types, .NET types, and Mixed types. Do not let the name Pure Perl types confuse you, as they are fully functional in the .NET environment and enjoy all the Core Perl benefits, but some .NET design possibilities are unreachable for them. The second (.NET types) will have more flexibility in using .NET features while being limited on the Core Perl side. Finally, the third (Mixed types), as their name suggests, mix the functionality of both Pure Perl and .NET types, but mostly they behave as .NET types. We dedicated this chapter to programming and designing of Pure Perl types. Chapter 12 concentrates on .NET and Mixed types in PerlNET. |
With component development, we achieve scalability and robustness for our applications. We also take advantage of other benefits:
Simpler and shorter code
Easier debugging[1]
[1] Currently, you cannot debug your PerlNET programs. However, ActiveState is working on adding this feature to Visual Perl.
Code reusability
Efficiency
Therefore, after convincing you in favor of the component development (hopefully, our explanation was persuasive), we demonstrate this technique with a simple example.[1]