Choosing a packaging model

As indicated in the previous section, you have many options for packaging an executable version of an application. Here are several of the most common packaging models you might consider.

A standalone executable file

In this model, you include everything (all objects and resources) in the executable file, so that there is just one file to deliver.

Illustration Figure 40-4 shows a sample of what this model can look like.

Figure 40-4: Standalone executable model

The diagram shows the executable file planner dot exe. The file contains startup code, all objects, and all resources.

Use This model is good for small, simple applications—especially those that are likely not to need a lot of maintenance. For such projects, this model ensures the best performance and the easiest delivery.

An executable file and external resources

In this model, you include all objects and most resources in the executable file, but you deliver separate files for particular resources.

Illustration Figure 40-5 shows a sample of what this model can look like.

Figure 40-5: Executable with external resources model

The diagram shows the sample executable file analysis dot exe, which contains startup code, all objects, and some resources. Arrows point from the exe file to separate resource files labeled status 1 dot b m p, status 2 dot b m p, and analysis dot i c o.

Use This model is also for small, simple applications, but it differs from the preceding model in that it facilitates maintenance of resources that are subject to change. In other words, it lets you give users revised copies of specific resources without forcing you to deliver a revised copy of the executable file.

You can also use this model to deal with resources that must be shared by other applications or that are large and infrequently needed.

An executable file and dynamic libraries

In this model, you split up your application into an executable file and one or more dynamic library files (DLLs or PBDs). When doing so, you can organize your objects and resources in various ways. Table 40-4 shows some of these techniques.

**Table 40-4: Object and resource organization with dynamic libraries**
To organize	You can
Objects	Place them all in dynamic libraries so that there are none in the executable file, which facilitates maintenance, or Place a few of the most frequently accessed ones in the executable file to optimize access to them and place all the rest in dynamic libraries.
Resources	Place most or all of them in dynamic libraries along with the objects that use them, which facilitates reuse, or Place most or all of them in the executable file to optimize access to them.

Illustration Figure 40-6 shows a sample of what this model can look like.

Figure 40-6: Executable with dynamic libraries model

The diagram shows a sample executable with dynamic libraries. The executable contains startup code and an execution library list. Arrows point from it to five separate p b d files. Each p b d file includes all objects from a pibble of the same name, and all resources needed by those objects.

Use This model is good for most substantial projects because it gives you flexibility in organizing and maintaining your applications.

For instance, it enables you to make revisions to a particular part of an application in one dynamic library. However, you must always rebuild the entire application and deliver all the dynamic libraries to customers whenever you make a revision to any library.

An executable file, dynamic libraries, and external resources

This model is just like the preceding one except that you deliver separate files for particular resources (instead of including all of them in your executable file and dynamic libraries).

Illustration Figure 40-7 shows a sample of what this model can look like.

Figure 40-7: Executable with dynamic libraries and external resources model

The diagram shows a sample executable, two dynamic libraries, and external resources. The executable, called benefits dot exe, contains startup code, an execution library list, and some resources. A d l l called benefits dot d l l contains all objects from the library benefits dot pibble and some of the resources needed by those objects. An arrow points from benefits dot d l l to two external resources labeled H r dot i c o and h r dot c u r. A second d l l, called framework dot d l l, contains all objects from framework dot pibble and some resources needed by those objects. An arrow points from it to an external resource called company dot w m f.

Use This model is good for substantial applications, particularly those that call for flexibility in handling certain resources. Such flexibility may be needed if a resource:

Might have to be revised
Must be shared by other applications
Is large and infrequently used