Lifecycle
The software development lifecycle of a Force.com project is much like an on-premise Web application development project, but with less toil. Many moving parts exist in J2EE, .NET, or LAMP projects. Most require a jumble of frameworks to be integrated
and configured properly before one line of code relevant to your project is written.
This section describes areas of Force.com functionality designed to streamline the development lifecycle and focus your time on the value-added activities related to yourapplication. Each of these areas has implicit costs and benefits. On the cost side, there is usually a loss of control and flexibility versus technologies with less abstraction. Evaluatingthese features and judging whether they constitute costs or benefits for your project is up to you.
and configured properly before one line of code relevant to your project is written.
This section describes areas of Force.com functionality designed to streamline the development lifecycle and focus your time on the value-added activities related to yourapplication. Each of these areas has implicit costs and benefits. On the cost side, there is usually a loss of control and flexibility versus technologies with less abstraction. Evaluatingthese features and judging whether they constitute costs or benefits for your project is up to you.
Integrated Logical Database
Relational databases are still the default choice for business applications, despite the availability of alternatives like NoSQL, XML, and object-oriented databases.The relational
model maps well onto business entities, data integrity is easily enforceable, and implementations scale to hold large datasets while providing efficient retrieval, composition, and transactional modification.
model maps well onto business entities, data integrity is easily enforceable, and implementations scale to hold large datasets while providing efficient retrieval, composition, and transactional modification.
databases introduces an impedance mismatch. Databases organize data in terms of
schemas, tables, and columns. Programs organize data and logic into objects, methods, and
fields. Many ways exist to juggle data between the two, none of them ideal.To make matters
more complicated, many layers of protocol are needed to transport queries, resultsets,
and transactions between the program and the database.
In Force.com, the database tables are called objects.They are somewhat confusingly
named because they do not exhibit object-oriented behavior.The name comes from the
fact that they are logical entities that act as tables when being defined, loaded with data,
queried, updated, and reported on, but are surfaced to programs as typed data structures.
No mismatch exists between the way data is represented in code and the way it’s representedin the database.Your code remains consistent and concise whether you are working with in-memory instances of your custom-defined Apex classes or objects from the
database.This enables compile-time validation of programs, including queries and data
manipulation statements, to ensure that they adhere to the database schema.This one
seemingly simple feature eliminates a whole category of defects that were previously discovered only through unit tests or in production by unfortunate users.
The logical aspect of the database is also significant. Developers have no direct access
to the physical databases running in Salesforce’s data centers.The physical data model is a
meta-model designed for multitenant applications, with layers of caches and fault tolerance,
spanning servers in multiple data centers.When you create an object in Force.com,
no corresponding Oracle database table is created.The metadata describing your new
table is stored and indexed by a series of physical tables, becoming a unified, tenantspecific
vocabulary baked into the platform’s higher-level features.The synergy of
integrated, metadata-aware functionality makes Force.com more than the sum of its
individual features.
schemas, tables, and columns. Programs organize data and logic into objects, methods, and
fields. Many ways exist to juggle data between the two, none of them ideal.To make matters
more complicated, many layers of protocol are needed to transport queries, resultsets,
and transactions between the program and the database.
In Force.com, the database tables are called objects.They are somewhat confusingly
named because they do not exhibit object-oriented behavior.The name comes from the
fact that they are logical entities that act as tables when being defined, loaded with data,
queried, updated, and reported on, but are surfaced to programs as typed data structures.
No mismatch exists between the way data is represented in code and the way it’s representedin the database.Your code remains consistent and concise whether you are working with in-memory instances of your custom-defined Apex classes or objects from the
database.This enables compile-time validation of programs, including queries and data
manipulation statements, to ensure that they adhere to the database schema.This one
seemingly simple feature eliminates a whole category of defects that were previously discovered only through unit tests or in production by unfortunate users.
The logical aspect of the database is also significant. Developers have no direct access
to the physical databases running in Salesforce’s data centers.The physical data model is a
meta-model designed for multitenant applications, with layers of caches and fault tolerance,
spanning servers in multiple data centers.When you create an object in Force.com,
no corresponding Oracle database table is created.The metadata describing your new
table is stored and indexed by a series of physical tables, becoming a unified, tenantspecific
vocabulary baked into the platform’s higher-level features.The synergy of
integrated, metadata-aware functionality makes Force.com more than the sum of its
individual features.
Metadata-Derived User Interface
As described previously, the definition of your objects becomes the vocabulary for other
features. Nowhere is this more evident than in the standard Force.com user interface,
commonly referred to as the “native” UI.This is the style pioneered by the Salesforce
Sales and Service Cloud products: lots of tabular displays of data, topped with fat bars of
color with icons of dollar signs and telescopes, and a row of tabs for navigation.
It is worth getting to know the capabilities of native UI even if you have reservations
about its appearance or usability.To some, it is an artifact of an earlier era of Web applications.
To others, it is a clean-cut business application, consistent and safe. Either way, as a
developer, you cannot afford to ignore it.The native UI is where many configuration
tasks are performed, often for features not yet visible to Eclipse and other tools.
If your project’s user interface design is amenable to the native UI, you can build
screens almost as fast as users can describe their requirements. Rapid application prototyping is an excellent addition or alternative to static screen mock-ups. Page layouts are descriptions of which fields appear on a page in the native UI.They are automatically
created when you define an object and configured with a simple drag-and-drop
layout tool.
features. Nowhere is this more evident than in the standard Force.com user interface,
commonly referred to as the “native” UI.This is the style pioneered by the Salesforce
Sales and Service Cloud products: lots of tabular displays of data, topped with fat bars of
color with icons of dollar signs and telescopes, and a row of tabs for navigation.
It is worth getting to know the capabilities of native UI even if you have reservations
about its appearance or usability.To some, it is an artifact of an earlier era of Web applications.
To others, it is a clean-cut business application, consistent and safe. Either way, as a
developer, you cannot afford to ignore it.The native UI is where many configuration
tasks are performed, often for features not yet visible to Eclipse and other tools.
If your project’s user interface design is amenable to the native UI, you can build
screens almost as fast as users can describe their requirements. Rapid application prototyping is an excellent addition or alternative to static screen mock-ups. Page layouts are descriptions of which fields appear on a page in the native UI.They are automatically
created when you define an object and configured with a simple drag-and-drop
layout tool.
Simplified Configuration Management
Configuration management is very different from what you might be accustomed to from on-premise development. Setting up a development environment is trivial with Force.com.You can provision a new development environment in a few clicks and deploy your code to it using the familiar Eclipse IDE.
When added to your Eclipse IDE or file system, Force.com code and metadata are ready to be committed to an existing source control system. Custom Ant tasks are available to automate your deployments. Sandboxes can be provisioned for testing against realworld volumes of data and users.They are automatically refreshed from snapshots of production data per your request. Force.com’s packaging feature allows you to partition
your code into logical units of functionality, making it easier to manage and share with others at your company or in the larger community.
Integrated Unit Testing
The ability to write and execute unit tests is a native part of the Apex language and
Force.com development environment.Typically, a test framework is an optional component
that you need to integrate into your development and build process.With the facility
to test aligned closely with code,writing and executing tests becomes a natural part of
the development lifecycle rather than an afterthought.
In fact, unit tests are required by Force.com to deploy code into production.This
applies to all Apex code in the system: user interface logic, triggers, and general business
logic.To achieve the necessary 75% test coverage often requires as much if not more code
than the actual Apex classes.
To make sure you don’t code yourself into a corner without test coverage, a great time
to write tests is while you code. Many development methodologies advocate test-driven
development, and writing tests as you code has benefits well beyond simply meeting the
minimum requirements for production deployment in Force.com. For example, a comprehensive library of tests adds guardrails to refactoring and maintenance tasks, steering you away from destabilizing changes.
Force.com development environment.Typically, a test framework is an optional component
that you need to integrate into your development and build process.With the facility
to test aligned closely with code,writing and executing tests becomes a natural part of
the development lifecycle rather than an afterthought.
In fact, unit tests are required by Force.com to deploy code into production.This
applies to all Apex code in the system: user interface logic, triggers, and general business
logic.To achieve the necessary 75% test coverage often requires as much if not more code
than the actual Apex classes.
To make sure you don’t code yourself into a corner without test coverage, a great time
to write tests is while you code. Many development methodologies advocate test-driven
development, and writing tests as you code has benefits well beyond simply meeting the
minimum requirements for production deployment in Force.com. For example, a comprehensive library of tests adds guardrails to refactoring and maintenance tasks, steering you away from destabilizing changes.
Integrated Model-View-Controller (MVC) Pattern
The goal of the MVC pattern is maintainable user interface code. It dictates the separation
of data, visual elements that represent data and actions to the user, and logic that
mediates between the two. If these three areas are allowed to collide and the codebase
grows large enough, the cost to fix bugs and add features becomes prohibitive.
Visualforce adopts MVC by design. For example, its view components do not allow
the expression of business logic and vice versa. Like other best practices made mandatory
by the platform, this can be inconvenient when you just want to do something quick and
dirty. But it is there to help. After all, quick-and-dirty demos have an uncanny tendency
to morph into production applications.
of data, visual elements that represent data and actions to the user, and logic that
mediates between the two. If these three areas are allowed to collide and the codebase
grows large enough, the cost to fix bugs and add features becomes prohibitive.
Visualforce adopts MVC by design. For example, its view components do not allow
the expression of business logic and vice versa. Like other best practices made mandatory
by the platform, this can be inconvenient when you just want to do something quick and
dirty. But it is there to help. After all, quick-and-dirty demos have an uncanny tendency
to morph into production applications.
Integrated Interoperability
Force.com provides Web services support to your applications without code.You can designate an Apex method as a Web service.WSDL is automatically generated to reflect the
method signature.Your logic is now accessible to any program that is capable of calling a Web service, given valid credentials for an authorized user in your organization.You can also restrict access by IP address or open up your service to guests.
As in other languages,Apex provides you with a WSDL-to-Apex tool.This tool generates Apex stubs from WSDL, enabling you to integrate with SOAP-enabled business processes existing outside of Force.com. Lower-level Apex libraries are also available for
raw HTTP and XML processing.
method signature.Your logic is now accessible to any program that is capable of calling a Web service, given valid credentials for an authorized user in your organization.You can also restrict access by IP address or open up your service to guests.
As in other languages,Apex provides you with a WSDL-to-Apex tool.This tool generates Apex stubs from WSDL, enabling you to integrate with SOAP-enabled business processes existing outside of Force.com. Lower-level Apex libraries are also available for
raw HTTP and XML processing.
End of Life
Retiring a production application requires a few clicks from the system administrator.Users can also be quickly removed or repurposed for other applications.Applications can
be readily consolidated because they share the same infrastructure. For example, you might keep an old user interface online while a new one is being run in parallel, both
writing to the same set of objects.Although these things are possible with other technologies,Force.com removes a sizable chunk of infrastructure complexity, preserving more intellectual bandwidth to devote to tackling the hard problems specific to your business.
be readily consolidated because they share the same infrastructure. For example, you might keep an old user interface online while a new one is being run in parallel, both
writing to the same set of objects.Although these things are possible with other technologies,Force.com removes a sizable chunk of infrastructure complexity, preserving more intellectual bandwidth to devote to tackling the hard problems specific to your business.
