what could be the better way of saving data using jsf

[Amee Dabo]

Hi,

Using JSF I am working on a simple example which saves employee data into database.I have :
1. Created a employee jsp which will have 'Save' button
2. On click on 'Save' button a method Employee backing bean's saveEmployee() will get called.
3.Via this method have given a jdbc call which inserts employee data into database.

My doubts:
1.Is this the correct way am I following? or is there any other better way of saving data using JSF?
2.My manager asked me to use Shale architecture along with JSF. But I am not at all aware how to use this Shale architecture. I went through the website but could not figure out how it can be used.Any inputs please?
3.Can you provide me good links for learning Shale architecture?

Thanks..

[Viswanath Sriram]

ya we can do this using save() in hibernate.create the bean object and set the data to the bean then save the bean object using sace method.you need not write the insert query to do this.

[Merrill Higginson]

There's certainly nothing wrong with writing JDBC code for data access. My only suggestion would be to extract the JDBC code to another class using the Data Access Object (DAO) pattern. That way you make sure your model logic is more loosely coupled to your controller logic in the MVC architecture.

[Amee Dabo]

Thanks Viswanath & Merrill. Nice forum..

[Tim Holloway]

In most cases, you'd pick either JDBC or one of the ORM technologies (EJB, JDO, Hibernate) to manage persistent data. JDBC has the advantage of being something you can hack out in a hurry. ORM has the advantage of allowing you to talk to the database in Java form. It's more trouble to set up, but scales up better.

JDBC, interestingly enough, benchmarks slower than most current ORM platforms.

A DAO layer allows you the flexibility to swap in and out for the persistence mechanism that works best - including a mock layer for testing purposes. The downside is some added complexity.

Spring is a nice thing to pair with JSF for persistency purposes, BTW. It's fairly lightweight, but it makes the individual modules simpler and more reliable, and it handles a lot of the repetitive "grunt work" for you. Once again, added complexity in terms of number of program parts, but the individual parts become simpler. The tradeoff being development costs versus what the progam will cost in ongoing maintenance.