CHAPTER 3 Domain models and metadata (Graphic web design) In this
CHAPTER 3 Domain models and metadata In this book, we won t have much to say about business rules or about the behavior of our domain model. This isn t because we consider it unimportant; rather, this concern is mostly orthogonal to the problem of persistence. It s the state of our entities that is persistent, so we concentrate our discussion on how to best represent state in our domain model, not on how to represent behavior. For example, in this book, we aren t interested in how tax for sold items is calculated or how the system may approve a new user account. We re more interested in how the relationship between users and the items they sell is represented and made persistent. We ll revisit this issue in later chapters, whenever we have a closer look at layered application design and the separation of logic and data access. NOTE ORM without a domain model We stress that object persistence with full ORM is most suitable for applications based on a rich domain model. If your application doesn t implement complex business rules or complex interactions between entities (or if you have few entities), you may not need a domain model. Many simple and some not-so-simple problems are perfectly suited to table-oriented solutions, where the application is designed around the database data model instead of around an object- oriented domain model, often with logic executed in the database (stored procedures). However, the more complex and expressive your domain model, the more you ll benefit from using Hibernate; it shines when dealing with the full complexity of object/relational persistence. Now that you have a (rudimentary) application design with a domain model, the next step is to implement it in Java. Let s look at some of the things you need to consider. 3.2 Implementing the domain model Several issues typically must be addressed when you implement a domain model in Java. For instance, how do you separate the business concerns from the crosscutting concerns (such as transactions and even persistence)? Do you need automated or transparent persistence? Do you have to use a specific programming model to achieve this? In this section, we examine these types of issues and how to address them in a typical Hibernate application. Let s start with an issue that any implementation must deal with: the separation of concerns. The domain model implementation is usually a central, organizing component; it s reused heavily whenever you implement new application functionality. For this reason, you should be prepared to go to some lengths to ensure
If you are in need for cheap and reliable webhost to host your website, we recommend http web server services.