> Contrary to what you might read online, it is > impossible to fully abstract away your persistent framework.
I didn't refer to any articles did i? > Take Hibernate for example, if you are inserting large > objects you will have manually flush/clear your session every > X inserts to avoid running into OutOfMemoryErrors. Other > frameworks handle this differently (in db4o for example, they > use weak references so you never run out of memory). Every > framework seems to have its own little "quirk" and you end up > with leaky abstractions. Ummm...look at the example I checked into cvs. You want to use db40 with it - provide a Db40ContactDao implementation, you want to use jdbc provide a JdbcContactDao implementation. NO CHANGES REQUIRED TO WICKET-RELATED CODE - thats what we were talking about. > > In my use-case, it makes a lot of sense to bundle > DB-aware methods with the POJO. For example, normally your > POJO would be: > where getCanonicalInstance() is DB-aware. There are a > lot of helper functions that manipulate or operate on themes > and I bundle them with class Theme. This simplifies my code a > great deal in exchange for the lack of separation between the > persistence and data layer (which is fine with me). Your > use-case might differ <shrug> You just havent run into situation where this is a problem. But your application is small so you never might. -Igor ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
