Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Very good question. It depends on your expectations for the evolution of your code. Returning persistent business objects means that the fact that you are using JDO (or something JDO-like, such as Hibernate or Castor) is leaking out of your DAO layer. How much of a problem this is needs to be weighed against the effort required to introduce a layer of value objects. Where I'm coming from this is generally not a problem; the likelihood of replacing the persistence technology by something wildly different is zero. It's also OK for the business layer to be aware of this (and careful about changing things), as long as the domain objects stop being persistent when they escape the business layer. In a different environment I might perhaps choose otherwise.Originally posted by Sean Li:
[...] what is the return result from DAO? Persistable business object? or values object?
You lose some of the isolation, but I would not say you lose the purpose of using a DAO layer. You are still isolated from the specific JDO or JDO-like tool you choose. You still keep your persistence logic away from your business logic.But if you do so, you lost your purpose of using DAO, cause only JDO supports that. Other persistence methods like ejb and jdbc don't.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
SCJP 1.4<br />(WIP) SCJD B&S v2.3.3
Eric LEMAITRE
CNAM IT Engineer, MS/CS (RHCE, RHCX, SCJA, SCJP, SCJD, SCWCD, SCBCD, SCEA, Net+)
Free Online Tutorials: http://www.free-tutorials-online.net/
SCJP 1.4<br />(WIP) SCJD B&S v2.3.3
Originally posted by Sean Li:
According to the definition from Sun's web site, we can see DAO is a layer to hide underneath data sources.
This is quite correct, DAO is a facade or control point for data access. Then you have the data objects and/ or data transfer objects served through this.
The point is that if the data mgmt/ storage are positioned *behind* the instances and orthogonal to usage, then your data/ access are already naturally decoupled from usage. This is a key design point which JDO got right. The DAO need only be only-liners and pass-thru methods since the mgmt functionality is transparent to usage.
By contrast EJB usage is *not* orthogonal to container management. The EJB design focused on network distribution by RMI and placed these semantics at the *front* of objects, on each and every method call :-(. This means EJB usage cannot be transparent or effectively decoupled from mgmt.
Technologies are changing so fast, from jdbc to ejb, then jdo, then ejb3, then whatever, who knows what's gonna to be in the nearly future?
What's most useful about a DAO layer, is not just technology but application requirements.
Using the simplest possible passthru layer is fine, as it gives you a place to engineer eg SpecialOrderPricing derivative rules when these become required.
What's going to be in the future, is Management of instances; because there's no more direct way to work with data, and this mgmt will be orthogonal (transparent) to application usage, rather then tripping code up with poorly-placed semantics.
There are only a limited number of architectural possibilities for data addressing and network semantics. Indirect = jdbc; direct = jdo, ejb, etc. Connection at back = jdo, jdbc; rmi on every method call = ejb.
Really what the JDO spec is, is not a standard for instance storage, but a standard for instance management. This is what you want, because it means your app code can address business data most simply and simpply ask the DAO to commit when complete.
Management is really fundamental to software, yet often neglected. (Every ClassLoading problem you've ever had, would have been diagnosed in 20 seconds - if Sun's classloader did not absolutely prevent mgmt above debugger level).
Cheers,
Thomas Whitmore
www.powermapjdo.com
Originally posted by Sean Li:
For example, I have "Order" interface, with defines all get/set methods of its properties, and also CRUD methods. Then we can implement this interface with JDO, or ejb, or purely jdbc, or whatever. This interface doesn't care about data source, doean't care about persistence mechanism. So, in business logic layer, business objects can use this "Order" interface freely. The interface is what I called DAO.
SCJP 1.4<br />(WIP) SCJD B&S v2.3.3
Originally posted by Sean Li:
About the comparision between JDO and EJB. I don't actually agree with your point. Ejb is designed and focused on distributed usage. But the Ejb here is not persistent EJB, I think that's Session Bean. In most cases, Session facade. Persistent Bean normally would not expose its interface to outside world.
Yes, Enterprise Java Beans are focused on distributed usage. Often the Session Bean (service rather than persistent data) will be used as a management/ service control point or Facade to provide access into the data.
But the point of EJB is distribution, the point of distribution is use, and the strongest commonality between layers is not the services (different layers have different services/ gateways into them) but the data which flows across them.
Then about shortcoming of persistent ejb. I think people don't like it just because it's too much complicated and hard to deploy and hard to debug. But, the idea of persistent ejb is the same with JDO, to create a domain object, and hide mgmt/store inside of the bean.
Big big distinction: management inside, vs outside, the item.
Self-managing objects fall into the same category as a self-managing traffic at an intersection or a self-conducting orchestra. Effective management (eg traffic light, conductor) is a completely different functionality from the individual item (car, bassoon player).
Trying to combine these functionalities is almost completely erroneous and has extremely poor performance with multiple data items. Basically every criteria of design is incorrect for combining these roles:
- functionality for the role
- stored data required for the role
- inheritance and differentiation
- collaborations with other services
eg. Managers will typically provide generalized CRUD implementations, whereas Entities must be specific to their data fields. Thus the Manager or Data Services provider is a different (often minimal) heirarchy entirely from the Customer, Order, Transaction etc entities.
eg. Managers must maintain HashMap of keys -> objects, individual Entity has nothing to do with this, map must be maintained per-session so static is still completely unsuitable (as well as inefficient and non-extensible), ...
BMP is ugly, cause you have to handle everything by yourself. CMP is powerful but not flexible, cause everything is handled by container. But CMP is also some sort of mapping between object and database tables. (We are talking about relational database here, it's impossiable for CMP to map non-relational data source.)
Yes, there are damn lots of ugly. This is one of the reasons JDO is such a favourable solution, it is clean and efficient and powerful. It's also very effective to program against.
The J2EE committee is nothing but trying to keep their market share, papering over the minor :-) problem that Entity Beans were the answer to the wrong question.
J2EE is great for Distributed Services, Messaging, Mail APIs etc but real applications don't scatter their fine-grained data across the network and the vendors are still trying to paddle the wrong way up the wrong creek (this is now increasing in steepness with a waterfall ahead, but just keep paddling those Entity Bean apps...).
Ok, let's go back to DAO. I don't know if you have read my another thread. I have an idea of hide all persistent mechanism, by defining an interface.
For example, I have "Order" interface, with defines all get/set methods of its properties, and also CRUD methods. Then we can implement this interface with JDO, or ejb, or purely jdbc, or whatever. This interface doesn't care about data source, doean't care about persistence mechanism. So, in business logic layer, business objects can use this "Order" interface freely. The interface is what I called DAO.
Keep OrderMgr and Order separate.
The functionality in OrderMgr, CustomerMgr, ProductMgr will also have major commonalities; may even share the same implementation but be constructed with a Order.class, Customer.class parameter to tell it which entity type to retrieve.
Then you keep the data and get/set methods on Order, and (most likely) a Session and some OrderMgrs, CustomerMgrs etc. Ideally you tell the Session to commit as updates typically include multiple data types.
The other major problem with self-managing persistent objects, which has been commonly recognized for over 8 years now, is that they can't be uniqued properly; in certain situations you'll get duplicate instances of the same object and consistency errors will start to enter your app.
Have a think about the implementation, you'll find that this design fits the problem clean and exact and correct.
I'd also invite you to download the PowerMap JDO trial and check it out, especially if you use Eclipse or even if you're just interested to check out the cool features.
Cheers,
Thomas Whitmore
www.powermapjdo.com
Entity beans are a far, far cry from transparently persisted POJOs - but I'll leave answering that one to Thomas, I think he can do it more justice. I did want to point out that managed transactions aren't the exclusive domain of EJB containers. I'm currently using Spring declarative transaction management and it works better for me than EJBs ever did.Originally posted by Sean Li:
[...] I don't think so, persitent enterprise java beans are initialized and managed by container. Exactely the same the JDO. More futher, you can hand over the transaction management to container.
I've been thinking a little about that when I started my current project. I do not claim to have the final answer, but I will give you a purely object oriented throught for your consideration. An order does not confirm. An order is confirmed. Therefore, the confirm() business method does not sit easily on the order domain object, but belongs on a business object which handles the process of order confirmation.An JDO persistent object is an domain object, am I right? If it's a domain object, why cannot I add business logic methods to it? For example, order.confirm(), or order.release().
How does a DAO reduce the power and flexibility of JDO? And, perhaps more contentiously, what is wrong with the DAO returning persistent business objects? The fact that they are persistent simply becomes part of their published API, although admittedly a part that is hard to implement with anything other than JDO, Hibernate, Castor and the like.If we don't have DAO, domain objects are persistence capable, there would be nothing between business logic layer and persistent layer, that would cause problem when converting from JDO to other persistent technologies. If we do use DAO, we really reduce the power and flexibility of JDO.
Please, no, not another Petstore!I think we need some sort of best practise of using JDO.
Surely that is quite independent of the persistence technology. Some projects transfer domain objects (however they're persisted), other uses DTOs. Neither is "wrong"; I think there's room for more than a single best practice here.[...] also we will have discuss about what to transfer between business logic layer and presentation layer.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Here. Have a potato. I grew it in my armpit. And from my other armpit, this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|