Within one Business Entity, it may be necessary to read or write data managed by other Business Entities as part of the business logic. To preserve the separation of the application's internal data representation from the details of the physical storage, which the Data Access layer does for you, it is important to access other data through its Business Entities whenever possible, which basically means whenever performance considerations do not force you to compromise that approach. There is, of course, an overhead involved in accessing data through the Business Entities. This requires performing a FILL to retrieve data, which copies it into temp-tables, manipulating the data in the temp-tables, and then copying any changes back to the database or other data source. If you work to package your business logic in "chunks" that make this type of operation as efficient as possible, then this can work effectively for most situations. Remember that the ProDataSet can often move data between the database and temp-tables, and perform other operations, more efficiently than you can in your own ABL code, and more efficiently than ABL-based objects such as SDOs.
Some limited operations that either involve processing large batches of data or doing extremely data-intensive operations against the database may suffer unacceptably from the use of Business Entities as a strict access interface to the data. You must decide when the internal data model needs to be compromised for these reasons, and carefully isolate procedures that bypass the entities and access the database or other data source directly. If you do this only when really necessary and keep the instance of it isolated and identified, then you should be able to manage schema changes or other application life cycle events that change the nature of the data source without too much difficulty. It is very important, however, not to fall into the trap of making direct access to the database because it seems the simplest way to write a section of code.
If you construct sensible APIs for your business logic, you can develop a coding standard that uses Business Entities effectively without the need to access the database directly. These standards should in fact improve the modularity, maintainability, and reusability of your business logic by forcing you to identify, name, and encapsulate logic operations that can be modified or reused elsewhere, rather than simply writing line after line of business logic that is not reusable and does not clearly identify what the purpose of each piece of code is. If your business logic is modular, you can much more easily add rules processing and workflow layers to your application that run, sequence, extend, and customize as a series of identifiable organized steps rather than an unorganized mass of ABL code.
