At this point, your design documents should include a good first cut at the business objects you need and how these objects should be grouped into components. You also have the data objects your business objects will rely on. As you look at implementing the business objects, keep in mind these key design points from Chapter 7:
- Business objects encapsulate real-world business operations, independent of how the data they use is actually stored.
- Business objects control sequencing and enforcement of business rules, as well as the transactional integrity of the operations they perform.
- Business object methods should do exactly one unit of work, and each unit of work should be implemented in exactly one method. Higher-level operations are composed by calling methods on other business objects and data objects.
- Business objects should work correctly whether or not the caller is transactional.
- Business objects that are called from the presentation layer should not retain per-object state across method calls. Business objects called within the presentation layer can retain per-object state within a transaction boundary.
- Business objects should be "network friendly." Minimizing the network traffic between remote presentation layers and business objects is important.
- Business objects are the "gatekeepers" that control access to your data. Role-based security should be used to restrict access to business objects.
- Transactions provide a straightforward model for handling errors generated within business object methods.
Business object implementations based on these design points are likely to be considered important company assets that will find use in many applications.