可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
Directly from this oracle article about the J2EE DAO Pattern:
Everything is very clear indeed but the Business Object "participant" (as they call it).
Here I quote the bit I would like more insights about (especially would be useful a real life example (an easy one)).
BusinessObject
The BusinessObject represents the data client. It is the object that requires access to the data source to obtain and store data. A BusinessObject may be implemented as a session bean, entity bean, or some other Java object, in addition to a servlet or helper bean that accesses the data source.
I am trying to use this pattern as an exercise (as a student for the exam OCPJP it requires to understand the DAO Pattern). So far I have my DataSource (mysql database), my transfer object (JavaBean called Person) and my DAO object interfacing properly between the database and the JavaBean (Person).
So again What exactly a Business Object is?
Thanks in advance
回答1:
Business objects are objects that concentrate all the logic of your application. Use Business Objects to separate business data and logic using an object model.
SEE HERE
回答2:
The DAO is responsible for getting a business object in a storage independent way. For example you can create a DAO for accessing a customer like
public interface CustomerDAO { public Customer getCustomerById(Integer id) }
and then implement a data access in jdbc
public class JdbcCustomerDao { public Customer getCustomerById(Integer id){ DataSource dataSource ...; Connection con = dataSource.getConnection(...); } }
or implement an CustomerDao that accesses a web service or whatelse. The advantage of the CustomerDao is that a client (the code that uses the CustomerDao) is independent of the concreate storage technology. That's why you should desing the DAO API without storage dependencies. A good hint is the import statements of the CustomerDAO interface. If the CustomerDAO import statements contain something like:
import javax.sql.***
you should re-think the design of your API. But keep in mind that you can also introduce API dependencies with strings. E.g.
public Customer findCustomer(String sqlWhereClause){ ... }
The business object holds the data an it is the place where you should put the domain logic at. If you are using a rich domain model approach.
For details see Concrete examples on why the 'Anemic Domain Model' is considered an anti-pattern
回答3:
I'm no expert in this, but I think the layman's explanation I would give to business object is this: business objects hold instance variables and attributes needed for a data access (e.g database) and business logic (for example, a Java class handling real operations) to communicate.
The business object usually does nothing for itself. For example, a phone can be a business object between a person and a news portal, the phone doesn't do anything itself, it just holds the browser and internet configuration settings needed by both parties.