Use DAO or not? in JDO

[Sean Li]

There are different opinions on this point, using DAO or not?

Our team leader said there's no neccessary to use DAO with JDO, cause create, update and delete method are already wrapped by JDO, we don't have to wrap it again. It sounds right.

But according to some patterns or best practises, mostly from J2EE, we should sepreate layers. Which means data access layer should not be bound to business logic layer. DAO class should only have CRUD and some queries. It sounds reasonable as well.

But I'm keen to the first one. cause less work are involved. Also, the objects returned from PersistenceManager are business objects. We can modificate them immediately, and the modification will reflect to database automatically after the transaction committed.

If we use DAO, what the result will be? Can we modify the result? Are they just value objects or operatable business objects?

I'm a little bit comfused, which way should we go?

Waiting for experts answer.

[Peter den Haan]

I do use DAOs in everything but the most trivial cases, even when using O/R mappers such as JDO or Hibernate. The DAO is there to isolate you from all persistence concerns. JDO is a persistence technology that business objects should not be aware of. Perhaps more importantly, in any nontrivial project you will get into situations where you have to implement something bizarre to get some tricky bit of persistence to work - manipulating your O/R mapping layer, bypassing it with some plain SQL, manually processing some associations that are hard to map, pulling extra data from a file or JNDI or whatever. IMHO that type of logic firmly belongs in a DAO.

- Peter

[Sean Li]

Thanks for your reply, but I'm still comfused.

You said you use DAO always, that means you hide JDO and other direct data access under DAO, am I right? Ok, my question is what is the return result from DAO? Persistable business object? or values object?

As you know, what JDO persistence manager returns are persistable business objects. Which means any change to it will reflect to database automatically.

If you use DAO and return persistable business objects to business logic layer, you must be very careful. Cause any change by intention or by mistake will be written to database. Or, you must be aware of that. Which means treat these objects as real database records. 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.

If you use DAO and return value objects, that's allright, you can really hide JDO. But does that mean you need to convert between persistable business objects and value objects? that's bizarre.

Do you get me? I'm not sure if I'm right or not. hope can get more idea from you, thanks.

[Peter den Haan]

Originally posted by Sean Li:
[...] what is the return result from DAO? Persistable business object? or values object?

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.

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.

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.

- Peter
[ July 30, 2004: Message edited by: Peter den Haan ]

[Sean Li]

Thanks, Peter.

I got what you mean. you think it's no problem to let the business layer be aware of the persistent object. and you do think DAO can hide implementation details from business layer.

Ok, that's good. and I got some idea from it. how about we do something like this: take a domain object as an interface. JDO is one of the possiable implementation of this interface.

so our structure will be:

presentation calls facade(delegate)
facade(delegate) calls domain objects
domain objects is implemented by all possiable persistent mechanism.

Do you get what I mean? This interface defines all get/set methods for all it's preperties, also defines business operation like CRUD. And some static methods for query(Queries have to be static methods, cause they don't belong to any of a certain instance. but to do this, we have to change the interface to be abstract class).

I think that's more object-oriented, and can totally hide data access. Or you can call that is another kind of DAO.

It looks like some sort of CMP bean, isn't it? But I think it's a good idea.

What do you think, hope I can get more idea from you. thanks.

[Peter den Haan]

Not sure I entirely follow you. Your facade (delegate) looks like what I would call a business object - traditionally a session bean, but can usually also be a simple POJO. If that is the case, then yes, that's definitely a good idea. There's no way I'd allow my presentation tier to call DAOs directly.

- Peter

[Robert Chisholm]

I can understand why someone with one primary data source in their company would question the value of a DAO.

However, I've had occasions where I've needed to get data from multiple data sources (ex: RDBMS, flatfile, web-service, XML etc) and subsequently persist that data to multiple data sources. I can't use an O/R tool like Hibernate to do all that.

However, I can wrap Hibernate up in the DAO (to say, replace my JDBC code) and my client or helper class will be none be the wiser. The only consideration is the usage of DTOs, as the above poster stated. I don't really have a problem with them... but others like Rod Johnson think they're evil.

[Sean Li]

Hi, peter, sorry about my poor English. But I think we are talking about the same thing.

Facade or business delegate is the thing between presentation layer and business layer. each facade or business delegate is incharge of a module.

Under facade or business delegate, there may be many small business objects.
These business objects call domain objects to implement business logic.

The domain objects here are interface or abstract classes, which hide persistence mechanism.

Let's take a user management as a example.

in presentation layer, struts calls UserFacade to verify user login.

UserFacade call User(interface) to get user information to verity username and password.

User(interface) declares many methods, like get/set methods of its properties, and CRUD methods, and query methods.

It is implemented by UserJdoImpl. UserJdoImpl is a persistent object, which implements all methods.

Do you know what I mean this time?

Do you think it's proper to put all query methods as static methods of a domain object? or how will you do it?

Thanks.

[Thomas Whitmore]

Hi Sean,

Definitely use a Service Facade, this should mostly be very simple and forms a 'point of control' if you need to change in the future.

Applications mostly consist of simple query & update usecases for fairly static data, with more complex usecases for core business transactions eg Orders.

So this is what your Service Facade should be implementing and the simple cases can be passthrus and one-liners as much as possible.

When you need other transfer forms or backend connectivity just having the place to implement this will be enough. (When you get here you'll probably also add interfaces to hide the impls of your business objects).

Keep it simple and best luck with your project!


Cheers,
Thomas Whitmore
www.powermapjdo.com

[Eric Lemaitre]

Hi all !

You can use DAO with JDO, but most of the time it will be useless because of JDO's "PersistentManagerFactory" notion which means choosing the concrete datastore (I avoid database term on purpose) you will be using. Datastore will be database almost always, but could be Object Oriented Database, flat binary file, XML text file, or others you could imagine. The most proficient JDO vendor right now is clearly LIBeLIS which handles "all" RDBMS + Versant + XML + binary flat file (called FDB), so widest range of datastore types for now.

But nothing prevents you implementing your own DAO, according to JDO vendor you use it could simply be useless as already implemented.

Best regards.

[Sean Li]

I think we should go back to the definition of DAO.

According to the definition from Sun's web site, we can see DAO is a layer to hide underneath data sources.

But, in my opinion, we can expand this concept. We can take DAO as a layer to hide persistence mechanisms.

In this case, I think we can use DAO to hide JDO.

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? (Don't tell me it's definetly JDO, that's noncense! Nothing is sure.) So, to protect the business logic layer from being affected by persistence mechanisms, use an interface between them. We can call that interface DAO.

[ August 09, 2004: Message edited by: Sean Li ]
[ August 09, 2004: Message edited by: Sean Li ]

[Robert Chisholm]

I use a DAO to hide Oracle persistence... and XML... and flat-files... and web-service... and... maybe JDO in the future

[Thomas Whitmore]

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

[Sean Li]

Hi, Thomas,

Sorry, I don't really catch you, entirely.

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.

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.

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.)

As we can see, people are working to simplify Ejb. And I can see the reason why they don't like sun approved JDO 2. Cause they think the idea is the same. I think these two technologies are similar either. (Sorry, maybe I should not say this here, forgive me, JDO fans.)

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.

What do you think?

[Robert Chisholm]

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.

This sounds like orthodox DAO to me.

Create an OrderDAO interface with methods like getOrderDetails or insertOrderDetails. Then implement that interface on your concrete DAOs, ex: OracleOrderDAO or XMLOrderDAO.

You can use a DAOFactory to pick which one you want.

[Sean Li]

Yes, exactely.

The only thing is the implementation can be more than just differnt data sources.

It can be JDO using Oracle, or BMP uing Jdbc to connect Mysql, or CMP to connect DB2, or JAXP to deal with XML, or whatever.

What it hides are not only data sources but also persistent mechanisms.
[ August 11, 2004: Message edited by: Sean Li ]

[Thomas Whitmore]

Hi Sean,

Good questions and let's consider this a bit more closely.

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

[Sean Li]

Hi, Thomas,

So glad to see your reply, I've been waiting for this for a few days.

About what your called: self-managing inside and outside. Sorry, I cannot acturally get you.

You think persistent enterprise java bean is some sort of self-managing stuff, and JDO persitent objects are managed by JDO implementation, don't you? 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.

Let's forget about BMP, focus on CMP. Using CMP, you define mapings between CMP bean and database schema, and you don't have to write any code to deal with database by yourself. It also has EJB-QL, similar to JDO-QL. From the point of usability, I admit JDO is better. But from the point of idea, I still think they are similar. (I know CMP doesn't support inheritance.)

Go back to JDO again.

To be honest, I don't actually satisfied with my DAO interface structure. I'm a little bit confused.

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(). Why do I need to bother with manager for just doing the same thing. And I think doing it this way is more object oriented.

But I agree with you about problems of keeping unique. When implemented with jdbc, it's really hard to maintain only one instance in memory.

So, what do you think is the ideal solution?

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.

I think we need some sort of best practise of using JDO. it's not only between business logic layer and persistent layer, also we will have discuss about what to transfer between business logic layer and presentation layer. Can we transfer JDO persistent objects to presentation layer to we have to create almost duplicate VO?

Tell me what do you think, and hope I can get more idea from you.

[Peter den Haan]

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.

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.

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().

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.

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.

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.

I think we need some sort of best practise of using JDO.

Please, no, not another Petstore!

[...] also we will have discuss about what to transfer between business logic layer and presentation layer.

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.

- Peter

[Sean Li]

First, let's forget about EJB, focus on JDO. I'm not from Ejb camp, I'm a small potato.

Ok, JDO with DAO.

Peter's idea is we need DAO, and there's no problem to let the persistent objects leak to business logic layer.

I don't understand. why? why it doesn't matter. If it doesn't matter, why should we use DAO? Why should we bother to have CRUD methods of every domain object implemented in DAO? JDO doesn't need that. I'm not saying that I object to it. I just don't understand. Could you explain this to me? What's the purpose of using DAO?

According to my understanding, the purpose of using DAO is to hide persistent implementation or hide data sources.

If it's to hide data sources, don't bother, JDO can handle that(ideally).

If it's to hide persistent implementation. Ok, let's take JDO and JDBC as example. Two implementations, but your business logic layer classes have to treat the result from DAO in different way. To JDO implementation result, cause it's still persistent object, you must be very careful to avoid changing it. But to JDBC implementation result, it's more secure. So, does the DAO hiding works? or works well?

To Order and OrderManager

Order is not a good example. I made a mistake of taking comfirm order and relase order as Order's own behavior.

Ok, this time, let's take Person as an example. eat and pee are two behavior of Person. Do you guyes still think I should have a PersonManager to deal with these two? Can I add these two methods to Person object?

Need best practise or not

I think we need it. Best practise is something like pattern, can definitely save developer's time, avoid making mistakes. Don't laugh at PetStore just because of EJb, ok?

So glad to discuss with you guyes. hope we can find out a best way.

I'm right here waiting for your answer.
[ August 17, 2004: Message edited by: Sean Li ]

[Thomas Whitmore]

Hi Sean, Peter,

Cheers :-) and thanks for your posts.


About what your called: self-managing inside and outside.[/Q]

Sean, you're quite correct that *behind* the scenes the EJBs have to be managed by the container, quite similar to how JDO or any persistence implementation will manage instances.

But the focus of the J2EE technology is network accessibility via RMI, rather than effective APIs for instance mgmt. Much of the front-end is the networking capability; and this is self-managed in that every public method can be subject to RMI'ification managed by the object itself. (There's a lot of mangling occurs during the deploy phase).

The focus on distant isolated objects, with the 'magic' networking capability, also encouraged the public mgmt APIs to focus towards single objects rather than operability in bulk. Not exactly self-mgd by the objects but mgd at one-cardinality which is just as inefficient. Really this spec was always quite far divergent from app requirements and this is why people have spent years doing anything Entity Beans :-)

[QB]
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.

Exactly. The Order may exist, be current, fulfilled, deleted etc in and ot itself. However creating or confirming the Order are not the Order's responsibility - but the responsibility of the application logic or manager or user, external to that Order.


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.

Here's the core of what your Data Access facade (DAO if you want to call it that) should look like.

OrderMgr. getById( Object id)
OrderMgr. getId( Order order)
OrderMgr. query( String filter)
OrderMgr. store( Order order) -- create or update
OrderMgr. delete( Order order)

Here's the core of what your Order should look like. Use getters/ setters for these; if you want a Data Transfer Object separate from the Data Object, implement an interface with just the getter methods.

Order. customer
Order. status
Order. dateTaken
Order. dateShipped
Order. totalAmount
Order. lines -- list of OrderLine


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.

The important thing about your Data Access facade is not to put complexity in there - keep it as simple as possible - but that it gives you a point to control or re-implement the logic.

You can implement the above DAO very nicely with JDO or any other data storage technology worth its salt - as a load of one-liner methods.

But then if you need, eg. worst case scenario here, to go back to JDBC - you can implement the storage and retrieval functionality in JDBC, using absolutely dumb vanilla Order and OrderLine objects. (You'd probably use IdentityHashMap to associate some tracking/ modification detection info with each instance).


According to my understanding, the purpose of using DAO is to hide persistent implementation or hide data sources. If it's to hide data sources, don't bother, JDO can handle that(ideally). If it's to hide persistent implementation. Ok, let's take JDO and JDBC as example. Two implementations, but your business logic layer classes have to treat the result from DAO in different way.

The purpose of any programming or design technique is its *utility*, not in conformance to some theory. OO is not by any means a complete or correct theory of programming, even at the fairly simple level Java operates. Note how hard it is debug Swing and ClassLoading stuff with all those distinctly unhelpful package-private barriers. (rant off)

Anyway, the real utility of Data Access Facade is a little bit different and there are some quite large benefits there.

1) Efficient place to implement complex business rules. If major lifecycle transitions are done thru the Facade, then rules like SpecialPricingThursday for combinations of items/ products can be implemented (and more importantly, changed) effectively when orders are entered. May involve the Order talking with the Mgr when calculating the total, but this is OK.

2) Efficient place to cache/ connect to secondary data - such as Products. Big tables of products, rules or whatever can be cached perfectly from/ thru this point where they might otherwise be completely non performant.

3) Implement custom queries/ reporting functions. These could be JDBC/ custom SQL even if your transactional code uses persistence.

4) Wrap/ control data sources & storage implementations. Same thing really - you've already mentioned both - but this is quite useful. The point is not really to hide them but to route them through a single point of control where you could add rules, caching or re-implement them - if you need to.

5) It's more about the ability to control and implement these in future, than making a complex implementation now. Keep it as simple as possible.



To JDO implementation result, cause it's still persistent object, you must be very careful to avoid changing it.

I'd go the other way. If the application changes it, it's because it needs to be changed -- and should be updated to the DB when committed (the user might also choose to cancel the session and not commit).

Apps are big and hard enough, that we need *enabling* technology rather than getting tangled up on spurious restrictions. And modifying/ updating the data is absolutely common for apps; so we might as well do that the straightforward way - by modifying the object.

Since we got the data from the Facade to start with, and since we're polite and tell the Facade to store after we've changed it, it is *absolutely* possible and indeed quite easy for the facade to know how to update this into the DB -- whichever method the internal impl uses.

So, in conclusion, it's ok to write to the objects! Business requirements can and should be implemented straight-forward rather than beating round the bush. So long as we notify the major lifecycle transition to a mgmt point, we're solid and futureproof 100%. This is a great thing to know!


Cheers,
Thomas Whitmore
www.powermapjdo.com