There will be other times when it may seem painful, and undesirably expensive, to reference all data through its Business Entity. In particular, some kinds of straightforward referential integrity checks, such as those which are typically done in traditional ABL through CAN-FIND functions and the like, will be significantly more complex and expensive if done through the data retrieval API of a Business Entity. Since the general recommendation in the past has been to use trigger procedures primarily for referential integrity enforcement, in order to make sure the database integrity is maintained no matter how the data is accessed, you should not hesitate to continue to do this level of basic validation check in database trigger procedures. It is important to keep in mind that to the extent that the internal Business Entity definition of the data differs in name or structure from the actual data source, a change in the nature of the data source will necessitate revisiting affected trigger procedures as well. If validation code that references database tables and fields in other entities directly is restricted to this layer, then this maintenance job can be kept under control.
In some cases, developers have used trigger procedures for substantial parts of their business logic, beyond basic integrity checks. This has not been the advised way of organizing business logic, partly because it can make the job of providing flexibility to that somewhat hidden logic more complicated, including customization of logic and changing parameter values for business logic calculations and decisions. Nonetheless, there can be advantages to this approach. In particular, since trigger procedures execute on the server-side of a distributed application, an older client-server-style application that has a large percentage of its logic encapsulated in trigger procedures already has done a lot of the separation of user interface from business logic that is required to make the application distributable between client and AppServer. Existing trigger procedures designed for client-server may still require changes, in particular to remove any MESSAGE statements or other user interface elements, and to make sure errors are properly returned in such a way that they can be transmitted back to the client. However, if you are going through an application transformation to provide a new user interface for an older OpenEdge application, you can consider leaving business logic in triggers at least for the first phase of your work, to simplify the amount of code rework that is required.
Again, the advantage is that at least you know where the code with the direct database table and field reference is. The disadvantage is that all the code that references those fields will need maintenance if the database schema changes, or if you need to substitute an entirely different data source type in the future. In addition, if the internal Business Entity definition differs from the database schema, there are then two different names you need to search for whenever you need to identify all the references to a particular data element.
To a large extent, the same applies to any existing application with business logic procedures that are already well adapted to a distributed environment. You will need to judge when it is most effective to leave complex logic procedures alone, providing some wrapper code for them as necessary to make them work in the new environment, and when it is better to rework them to use your Business Entity definitions. You do not need to make a hard and fast decision from the beginning of the process. It may be most practical to leave these procedures isolated while you are reworking the architecture of the rest of the application, and then address them at a later stage. Keep in mind that other aspects of a new application architecture should include standardized, flexible support for customization and personalization, language translation, application security, and other important features that can be supported in a standard way in a new architecture, but which are likely supported in a more ad hoc manner, intermixed with the real business logic, in older existing procedures.
