You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by Apache Wiki <wi...@apache.org> on 2005/11/18 19:38:09 UTC

[Myfaces Wiki] Update of "Hibernate And MyFaces" by Pauli Ojanperä

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by Pauli Ojanperä:
http://wiki.apache.org/myfaces/Hibernate_And_MyFaces

The comment on the change is:
ChangesShouldProbablyBeOverviewed.TryingToClarifyTheOriginalAuthor'sIntentSome.

------------------------------------------------------------------------------
  
  == The select items approach with a pure DAO approach ==
  
+ The above example although tight and convenient introduces a heavy depence between the dao layer and the user interface layer, if you can rely on non changing user interface techniques, it is a valid approach. However the classical DAO approach tries to capsule the data access and also does not have any dependency into the user interface or business logic of the application.
- The above example although tight and convenient introduces a heavy depence between the dao layer and the user interface layer, if you can rely on non changing user
- interface techniques, it is a valid approach. However the classical DAO approach tries to capsule the data access and also does not have
- any dependency into the user interface or business logic of the application.
  
  Hence a different approach might be more appropriate if it can be expected that the DAO has to deal with different frontend technologies.
  
@@ -285, +283 @@

  
  The easy way a data table only needs a collection of elements, hence a dao which delivers a list of elements can be used.
  [Example will follow]
+ However this approach is heavy on the memory because every dataset on the list has to be loaded into memory.
+ A simpler approach would be to feed lists into the data model, but this approach disables paging.
+ Therefore under normal circumstances, the data model approach has to be followed.
- however this approach has one downside, it puts heavy burden on the memory because every dataset put into the list has to be
- loaded.
- The cleaner but with a classical dao approach which should not introduce UI dependency elements into the DAO enforcement close to
- impossible to implement way is to use a data model.
  
  === Data model, Data Table the hard way ===
  
- The implementation of a data model class for the data table is much more complicated. JSF knows 
- the so called data model, as model class
- for a single data table. A specialized data model for the  table on a case per case base.
- A simpler approach would be to feed lists into the data model, but this approach disables paging.
- Therefore under normal circumstances, the data model approach has to be followed.
+ It is more complicated to implement a data model for a database table.
+ This technique also introduces unwanted dependancies between the UI and the DAO's.
+ JSF defines a DataModel interface and convenience implementations such as ListDataModel
+ for use with the DataTable UI component. DataTable knows the DataModel interface and
+ uses it to access the bound database data.
  
+ The main problem of implementing such data model is the unsophisticatedness of the interface.
+ Basically, it is an interface for
+ - retrieving total number of records or,
+ - retrieving data for a record at the current or given position.
+ No services are offered for iterating through records.
- The main problem of implementing such da data model is its, interface simplicity. A basic data model
- merely is a relatively simple interface which asks yofor the number of total records and requests
- to give back a record at the current position or at a specialized position. 
- To the worse it does 
- not even have a direct feedNextObject function, which makes the datafeeding upon given recordset objects and
- iterators more complicated than it should be.
  
- 
- So Implementing such a class for Hibernate is not easy, unless somebody one day will provide
+ So implementing such a class for Hibernate is not easy, unless somebody one day will provide
- a generic class which then can be used simply by pusing down a hibernate query objects and then let things do their way.
+ a generic class which then can be used simply by pushing down Hibernate query objects and then let things do their way.
- But up until now there is no such mechanism currently in existence.
  
  The [http://wiki.apache.org/myfaces/jsf-comp jsf-comp] project currently provides a mechanism for generic mappers which uses prefetch caching instead of automated session 
+ handling and direct feeds to accomplish such a thing. Unfortunately it is more complicated than an automated session handler or Hibernate query object approach would be, but it gives a good starting point on how to implement a specialized data model.
- handling and direct feeds to accomplish such a thing. Unfortunately it is more complicated than an automated session handler / hibernate query object
- approach would be, but it gives a good starting point on how to implement a specialized data model.
  
- Also several datamodels can be found in the MyFaces sourcecode.
+ Several datamodels can be found in the MyFaces sourcecode also.
  
  Examples for working springConfigs and web.xml s for the integration of MyFaces 1.0.9 and Spring as well as Hibernate 3
  with the Spring-JSF Integration library can be found