The first one uses an external file to define what mapping classes are used, the other its hardcoded in the class. So its basically the difference between using configuration file or hardcoding values. Hardcoding is usually considered to be a bad idea, but here is could be argued it is justified; how often do you add/remove tables from the DB or update the SessionFactory during runtime? [ January 18, 2005: Message edited by: Paul Sturrock ]
Thanks for help. I think the first approach will use all mapping files, while the second will use the specified ones, right ? so, it is better to use the first method. (I'm new here, so please, be patient)
I think the first approach will use all mapping files, while the second will use the specified ones, right ?
Not quite. Both will use all specified mapping files, its just where they are specified that is different. If you use the first approach Hibernate will look for the file hibernate.cfg.xml and try to load the mapping files specified in there. If you use the second, it will only load those you specify with the addClass method. For beginners, the second approach is often easier, since you don't have to chase down any issues with Hibernate not finding hibernate.cfg.xml.
thanks, but one more thing : when I dropped hibernate.properties file from the application, the application still works, but when I dropped hibernate.cfg.xml, I got an error. so when to use the properties file ? if hibernate.cfg.xml is already contains informations about the database, why we use a properties file ? hibernate docs says that this file should always be used.
Flexability I think. The schema (i.e. the mapping files) never change, but other properties can do. For example you can use the properties file to define the debugging options and swap properties files without changing how the SessionFactory is configured via hibernate.cfg.xml. I also suspect that it is also legacy, because there isn't anything you can put in hibernate.properties which you couldn't now put in hibernate.cfg.xml. [ January 20, 2005: Message edited by: Paul Sturrock ]