It is often said that developing an application can be a straight forward process. And it is. Developing a more complex application takes a lot more planning and the use of a number of the more advanced features

Over the years, many of us have learned lessons that have helped us to establish some best practices to be followed by developers. These are not really difficult, but they do make the application more robust and supportable

It would be very difficult to try and produce an exact and exhaustive list that represents all of the best practices to be followed. Some senior developers may prefer things one way as opposed to another. There are, however, some fundamentals on which we can all agree. This article presents some of them.

  1. Think about security from the start.

If the security of the application is not planned from the very start of your development will be very hard to implement security measures later. More recent versions of Apex already implement key security features, there are still a series of vulnerabilities that need to be addressed.

Whether your application is deployed on an intranet or the internet, security is an important issue. You need to create a security plan right from the beginning so that all developers can implement required security as they develop pages and components.

  1. Let the database do what the database is designed to do.

As much as possible, keep the application logic in the database Create packages and procedures in the database that are called from the application. If the business logic has to change, there is only one place to change it. This practice includes all DML actions required by the application. In other words, the application should not have any insert, update or delete processes, but rather should be calling APIs to perform the tasks.

The temptation to put functionality in the application is strong. When you are developing this just seems more practical. But, you will regret it later. Having to hunt through your application to find where you did something can be difficult and the repetition of the same pieces of logic in your application is likely.

You won’t find many senior Apex consultants that would disagree with this practice. Your application is then simply a presentation layer on top of the database. It will run faster and probably will be smaller.

  1. Query views rather than base tables.

Similar to the previous practice, this really has to do with keeping the queries reusable and making the queries in the application less complicated. If a new column is required in a report, we merely change the view and not the query in the application. And this way the application really does not know anything about the base tables. Your queries will not require any joins and will run very quickly.

Building the views and ensuring reusability may take a bit of time but either you spend that time within the application or within the database is really the same thing. Typically these views will reside in their own schema and employing the principle of least privilege. Your application will only have access to these views and not to the data schema.

  1. Avoid developing really large applications.

Apex can have applications with thousands of pages. Imagine as a developer trying to work your way through that when it is time to implement new requirements or sort out a bug. Testing becomes nearly impossible and the business will likely have to wait a long time for the development to be complete. By the time the application development is complete, the business requirements will likely have changed.

Where ever possible, divide the business requirements into functional stand alone modules. The users can move seamlessly from one module to the next, but there is not an unwieldy application that is difficult to upgrade or support. Obviously this only applies to larger business systems, but it does emphasise the importance of keeping things manageable and efficient.

  1. Make use of page aliases and page groups.

It is a good practice to assign an alias to each page. This alias can both give an indication of the page’s role in the application and sort things out when page numbers change.

Assign all pages to page groups. Create page groups for each functional area of the application and then assign one or more pages to that group. When you query a list of pages in the application, you will be able to use their page groups as a way of filtering the pages involved in a functional area.

Many developers relatively new to Apex ignore these values. But they are a key part of organising things.

  1. Changes must only be made in your development environment.

This seems obvious, but there is a great temptation to quickly change something in Test or Production. If you do this, you will never keep the various versions of the application in sync. While you might never do this in other frameworks, Apex holds a higher temptation because it is quick to change something especially when a UAT test is failing.

When you deploy your application to Test and Production, you should do so in Run Application Only mode by doing this, none of your developers will be able to edit the application in any way.

To really enforce this practice, you might even consider setting up Test and Production as runtime environments where there is no application builder or workspace access at all. There are some implications of doing this, but it is something you may want to look into further.

  1. Keep the required application files in Static Files.

In earlier versions of Apex, we would have probably considered placing our application files on the web server. They would have been faster to access. Since Apex 5, accessing files from the database has become much more efficient.

The advantage of loading the files into Shared Components is that the files become a part of your application. When you deploy the application to another environment, the files are automatically part of the deployment. If you store the files on the web server, it is an extra step that you must remember to do as a part of the deployment.

  1. Clean up after yourself.

When developing an Apex application, developers often create extra page items just to help them understand what is going on. They may even develop regions that they hide and never intend to display. Further, we will sometimes create a page just for trying something out.

These hidden or extra application components should be deleted when you are finished your testing. If they remain in the application, they will be confusing to other developers in the future. Get into the practice of removing them after the development of each page.

This also applies to workspace applications. Sometimes a developer may export an application and then import it into the same workspace with another application id. They might do this to keep a second copy or to be able to copy a component to the original application. Be sure to delete these applications later or you end up with a great deal of confusion.

  1. Write your code as you would anywhere else

Just because you are writing code in an Apex application is no excuse for not properly writing it. You need to version the code as well as write meaningful comments. You might know what your code is doing, but other developers may not interpret it correctly in the future.

  1. Sequence your pages in a meaningful order.

As an application is developed, it is sometimes the case that a single functional area is split across many pages all over the place. This makes everything rather messy and confusing. It is wise to set aside a specific page range for each functional area. By doing this developers will know exactly where they should add the pages.

For instance, you might set aside a page range starting at page 100 for customer related functional. Page 200 would be the starting range for Product related functionality.

Pin It

Contact Us

Please let us know your name.
Please let us know your email address.
Invalid Input
Please write a subject for your message.
Please let us know your message.
Invalid Input

Contact Us

Our Address

AppLinks (Pty) Limited
20 Wildebees Street
Alberton, South Africa
+27 (0) 11 902 3688
+27 (0) 83 276 3315