Several days ago, I finished reading the book-POJO in Action. I really benefit a lot from this book, therefore, in the next few days, I would like to write some conclusions about this book combined with my own thought.
In the chapter 2 of this book, the author lists 5 design decisions we need to make when we design the business logic layer of a system. The five decisions are:
- How to organize the business logic?
- How to encapsulate the business logic?
- How to access the database?
- How to handle concurrency in short transactions?
- How to handle concurrency in long-running transactions?
Next, I am going to explain the five questions one by one?
How to organize the business logic? Martin Fowler thinks that there are three patterns to organize the business logic, Transaction Script, Domain Model and Table Module respectively. The concept of Transaction script is procedure-oriented programming, so it is suitable for simple applications. The concept of both Domain Model and Table Module is object-oriented programming. The differences between them is that Table module maps a class to a table, and Domain Model maps a class to one row of a table. The common experience is that it is hard to maintain the application realized by Table Module. So Domain Model is usually our first choice to organize the business logic.
How to encapsulate the business logic? In a layer architecture, we need to make each layer independent to its neighbor by encapsulating each layer to hidden the detail. Usually, we think that the best practice to do that is using facade pattern. However, sometimes, because of the problem of open session in view, we cannot apply the facade pattern everywhere, instead, we have to choose Exposed Domain Model pattern, which let the present layer access the business model directly instead of the facade interface. It is obvious that both facade pattern and exposed domain model have advantages and disadvantages, and choosing which one depends on the the requirement of the applications.
How to access the database? Currently, there are several ways to access the database, for example, using JDBC to access the database directly, using iBATIS and uing ORM framework. Just as I said in a former article – find balances between technologies, there is no rule to direct us to adopt one and abandon the others. By the way, according to the popularity of the ORM framework, most people select it as their first choice. However, please remember it is not absolute.
How to handle concurrency in short transactions? Usually, we call short transactions database transactions, and long-running transactions application transactions. According to the author of the book of POJO in Action, we can use optimistic locking or pessmistic locking to handle concurrency. Optimistic locking derives its name from the fact it assumes that concurrent updates are rare and the application detects and recovers from concurrency instead of preventing them. However, the pessmistic locking assumes that concurrent updates will occur and must be prevented.
How to handle concurrency in long-running transactions? The author also lists two methods to deal with this problem, optismistic offline locking and pessmistic offline locking. The differences between them are the same as the ones between optismistic locking and pessmistic locking.
I hope the information above can give you a little bit help. By the way, The design of business logic is a very complicated question. Sometimes, even though you have a good knowledge of the concept of designing, you still cannot make a good work, because experience plays an important role in the process of desinging.