Book Image

Java EE 8 Design Patterns and Best Practices

By : Rhuan Rocha, Joao Carlos Purificação
Book Image

Java EE 8 Design Patterns and Best Practices

By: Rhuan Rocha, Joao Carlos Purificação

Overview of this book

Patterns are essential design tools for Java developers. Java EE Design Patterns and Best Practices helps developers attain better code quality and progress to higher levels of architectural creativity by examining the purpose of each available pattern and demonstrating its implementation with various code examples. This book will take you through a number of patterns and their Java EE-specific implementations. In the beginning, you will learn the foundation for, and importance of, design patterns in Java EE, and then will move on to implement various patterns on the presentation tier, business tier, and integration tier. Further, you will explore the patterns involved in Aspect-Oriented Programming (AOP) and take a closer look at reactive patterns. Moving on, you will be introduced to modern architectural patterns involved in composing microservices and cloud-native applications. You will get acquainted with security patterns and operational patterns involved in scaling and monitoring, along with some patterns involved in deployment. By the end of the book, you will be able to efficiently address common problems faced when developing applications and will be comfortable working on scalable and maintainable projects of any size.
Table of Contents (20 chapters)
Title Page
Copyright and Credits
Dedication
Packt Upsell
Contributors
Preface
5
Aspect-Oriented Programming and Design Patterns
Index

Explaining the business-object pattern


As the name suggests, a business object represents something in the real world and something associated with the business of the application. A business object is like an actor in an application use case. Examples of business objects include bank accounts, car insurance, college professors, students, employees, purchase orders, and payable or receivable accounts.

 

 

When it comes to simple applications with very little business complexity, that is, with few (or no) business rules, there may not be a need for a BO in the system. Better yet, a POJO entity that represents a database entity can be considered a BO. It is important to see the difference here. An entity or aPOJO representative of an entity (such as a JPA POJO ) is closer to the technology and structure than to a business-model object. So, for this example, an entity such as a college student can also be considered a BO or an actor of a college student use case.In fact, in these simpler cases...