The name of this question is jsf_dao_interface
Hello and Thank you in advance for any assistance.
The Purpose of this post is:
I am trying to learn to use an interface. I was wondering if someone was familiar with using and or had info on using DAO (data access object) classes.
The functionality of this code is:
The Model beans define the properties that must be saved into the database.
View beans extend the model beans with UI-specific code: actions, validates, etc.
JSF creates instances of the view beans as specified in the faces-config.xml file, but the persistence layer of the example application works with model beans.
Therefore, the application needs a utility method like ModelUtils.copy(), which copies the properties of the view beans instantiated by JSF into the model objects created by the persistence layer, and vice-versa.
The ModelUtils class also lets you get the model resources (such as configuration parameters, SQL statements, and error messages) from a resource bundle named ModelResources.
Finally, ModelUtils has a getLoggedInDAO() method that returns an instance of the LoginDAO interface that defines the methods for selecting, inserting, updating and deleting Subscriber objects from/into the relational database.
The data access methods are called from the action methods of the view beans.
Each action method is bound to a submit button in a JSP page
When the user clicks the button, the Web browser sends the form data to the server.
The JSF framework validates the form data
and returns the form to the user if there are any errors.
Otherwise, the valid form data is stored into the properties of the managed bean, and JSF calls the action method that is bound to the clicked button.
My question is:
Could someone supply some examples or links to examples of the use of this structure? I only have one example and it uses Oracle and that is matters even more confusing.
The errors related to this code are:
Code description: JDBCLoginDAO.java (the code is a starting structure with many errors. Future questions related will be presented. So I can understand how to correctly write my application specific code).
James, the rigour with which you frame these questions does you credit, but their sheer magnitude makes them virtually impossible to read on-line.
I can tell you that in my apps, the DOA/dataservice layer is constructed by the Spring Framework, which is responsible for both instantiating the access objects and for injecting the JPA entityManager objects that provide the actual JPA database connections into those access objects.
A special clause in the faces-config xml file connects the Spring Framework to the JSF framework so that these objects can then, in turn, be injected as properties into JSF backing beans, if they need data access services.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Mar 14, 2009
Yes, I totally agree. Thanks for the feed back.
With a project that uses the MVC structure. It is impossible to write one sentence questions. I have the entire project (every line o code and evey package outlined in a .xls (exel) program. If this could be uploaded then someone with training could quickly use the sentence.
What is my LoginInfoDAO.java class missing. or how is it wrong.
and solve the problem.
I guess having a repository for running a program on a server is out of the question.
but I was just trying to understand the class (interface) as it interacts with the model and the view.
On the bright side I did find a good place to start over and try to learn it some more. It should keep me busy for a while.
Haven't you heard? IT is so simple a child can do it!
If you can't make an enterprise-grade application simple in and of itself, the next-best approach is to make the overall structure simple. To that end, a common approach is to use various technology frameworks that allow the creation of simple components and permit these components to be wired together so that, while the overall application may be complex, at least no single component will be overly complex and the rules that interconnect components will likewise be simple and straightforward.
I don't have much use for the DAO paradigm anymore, outside of the persistence layer itself. DAOs provide primitive access to domain model objects, but for business purposes, that can be a real annoyance when you've got a lot of cross-linked objects and you're using an ORM persistence framework - which I recommend doing. JDBC is actually less efficient in large-scale systems, and it's a lot more coding and maintenance, so that raises the cost of the software product, both near-term and long-term. Also, since the DAO paradigm is all about the details of the database, it couples business functions to database architecture more tightly than the service data approach.
The service data approach involves providing data access functions based on business needs. This historically has been a function of Session EJBs, but with the JPA/EJB3 architecture, it's also possible to use POJO service objects as well - especially if you are using a framework such as Spring to handle the transaction management parts.
Just as an example, to retrieve a familiar parent-child arrangement such as an Invoice, you'd need 2 DAOs. One for parent (invoice header) and one for the invoice detail items. With a service interface, you might have methods that just retrieve the invoice headers, but you might also have methods that retrieve the invoice details along with the header so that the entire invoice structure would be available as a unit.