,

Introducing Apex

Before you can begin to learn about the syntax and capabilities of Apex, you need to learn the basics—the whats, hows, and whys of Apex.

What is Apex?

Apex is a strongly-typed, object-based programming language that allows developers to execute logic, flow and transaction control statements on the Force Platform. As you would expect, Apex is intimately connected with Force Platform data, offering powerful data interactions through both a query language and a search language.

You will learn most of the basic syntax in this chapter, with the next chapter devoted specifically to Apex data access and manipulation.

How Can You Use Apex?

Apex logic can be used in two different ways:

• In a database trigger - A trigger is executed in response to a particular type of database interaction, on a particular Force Platform data object. For instance, you can have a trigger that is fired whenever a new Job Application record is inserted into the object.

• In a class - You also have the option of creating Apex classes. You can call a class from a trigger.

Apex triggers are called implicitly in response to a database action, but you can call an Apex class explicitly from several different places on the Force Platform. Apex classes can be used to implement email-to-Apex services, described in Chapter 13: Email Services with the Force Platform, Visualforce controllers, and web services, described later in this chapter. You can also call methods in a Apex class from the Force Platform IDE’s interactive code window, or with the executeAnonymous method, described later in this chapter.

You can create Apex code in a Developer Edition organization or a Force Platform Sandbox, which is a copy of a production organization. Once you have completed your development effort and created test methods for the code, you can begin the process of deploying your code to a production environment, described in Chapter 15: Deployment.

As part of this deployment process, your test methods must successfully execute and provide over 75% code coverage. Once you have achieved this coverage, you can then deploy from either of these environments to your production organization.

The overall process is shown in the figure below.

You will learn about creating test methods later in this chapter. As mentioned above, Chapter 15: Deployment is devoted to deploying Force Platform applications.

Why Required Testing?

As you may have noticed in the previous description, all Apex code deployed to production environments must include test methods. When you deploy Apex triggers and classes, the Force Platform checks the test methods to make sure that these methods exercise at least 75% of the code in your trigger or class—greater coverage insures greater benefits.

For those of you who are used to working in a structured development environment, this requirement does not seem unusual, since you are no doubt already including test methods in your code. For others, this condition can seem overly strict, but there are two very good reasons behind the requirement: general best practices for development and best practices for maintaining your application over time.

You have already experienced, repeatedly, the enormous productivity of the Force Platform, from creation of sophisticated functionality to instant deployment. This instant deployment might tempt you to rapidly implement functionality on the fly without proper testing—a practice which is always rife with danger. By requiring test methods, the Force Platform insures that you follow best practices for development on any platform. The Force Platform includes the ability to run all of your Apex test methods with a single button push or menu selection, giving you a productive way to carry out the best programming practices.

The most important aspect of test methods relates to the certainty they give to all developers. As you may know, the Force Platform delivers an ongoing stream of enhancements, typically three major releases a year. The good news is that all of this innovation comes directly to you, without any effort on your part. New releases are streamed into the Force Platform—no installation chores for you.

But those of you who are experienced developers may see this rapid improvement of the platform as a potential threat to the stability of your own applications. If you have been developing applications for very long, you have probably already experienced a situation where a new platform or product upgrade broke your beautiful application.

You never have to worry about an upgrade accidentally disrupting your Apex code, since the Force Platform supports multiple versions of the Apex runtime environment. When a new release comes out, your application will automatically run with the version of Apex with which it was initially compiled.

But what happens when you want to move your application to a new release, to take advantage of new functionality or other features? By using test methods, you can protect against this possibility. Your test methods should be designed to exercise all the crucial logic in your Apex code. When you move your application to a newer release, you can simply run your test methods against the new release. If your test methods work properly, you don’t have to worry about new Force Platform releases affecting your own code, which greatly reduces the impediments to adoption of a new release.

How Is Apex Different?

Apex is a robust procedural language – but not the only robust procedural language which can access Force Platform data and platform functionality. Other languages, from .NET to Java, to JavaScript, can also access much of the functionality of the Force Platform, from procedural language and the use of the Force Platform Web Services API.

In fact, if you have been around the Force Platform for a while, you might have already implemented s-controls, which use Javascript to access the platform from the browser. How is using Apex different from using s-controls or these other languages?

The primary difference is where Apex executes. Apex logic runs on the Force Platform, eliminating the need for network traffic between a client and the Force Platform via the API. This different architecture can have a very large effect when doing data manipulation, since you will not have to bring data down to the client in order to make changes.

Apex code is tightly integrated with the rest of the Force Platform environment, leveraging the same metadata-driven productivity offered by the rest of the platform. This integration also gives a seamless interface to the rest of the functionality of the platform, an integration that continues to grow as the platform continues to expand.

Finally, the tight integration of Apex and the Force Platform means that Apex code works in concert with the rest of the platform. You can see the dependencies for any Apex class with the click of a button. Apex code is also automatically aware of changes in Force Platform metadata, so that a change in that metadata leads to automatic recompilation of Apex triggers and classes the next time those components are executed.

Over the course of the next two chapters, you will learn about Apex code, as well as how to best utilize these advantages in your own Force Platform applications.