# When to Put Code in an Application Module or a View Object

An Application Module can store application-specific code on the middle tier. For example, suppose a View Object named `EmpView` is shared by two client applications, and one client needs to calculate the sum of all employee salaries each time a row is added to the view. You could add the code directly to `EmpView`, but doing so increases the effective size of the object, adding to the processing burden on every client and application that uses it. A more efficient approach is to add the code to the Application Module. That way, the custom code is available only to clients that need it. Figure 1 shows both approaches.

#### Figure 1: Adding Code to a View Object versus Adding Code to an Application Module

Code attached to an Application Module executes in the middle tier, which might be more efficient than executing the code on the client. For example, suppose a client form needs to calculate a value based on values in a table. If that table contains (for example) 130 rows, the calculation requires that all 130 rows be brought to the client, resulting in 130 network round trips. Client-side performance can deteriorate when working with large tables.

#### Figure 2: Executing Code on the Client, Requiring Multiple Round-trips to the Server

When the code resides in the Application Module, the data stays in the middle tier. Performance is optimized, because the client gets the result in a single network round trip. The Business Components for Java framework handles the details of making selected Application Module methods available to clients.

#### Figure 3: Executing Code on the Middle Tier, Requiring Only One Round Trip to the Server