I'm currently on to refactoring our codes; making action classes not bulky, services simple and precise, and daos not calling other daos. I'm also sharing some of the parameterized mapper.
*****
I just finished refactoring category and role actions, services and daos. I just find something weird. In my category/update-cat.ftl, from the textfield, when I hit the enter key, it automatically "clicks" the Save button. However, in my role/update-rol.ftl, from the textfield, when I hit the enter key, it throws an exception: that I didn't declare a SUCCESS result type in my struts.xml, so I had to manually click the button save to make it work. I'm comparing the 2 ftls and struts.xml and currently, I can find no reason why such a thing is happening. Also, my two actions never return SUCCESS nor do I have execute methods.
*****
I just added role-user mapping when adding users. I wanted to eliminate the roleIdList of List<Integer> type in my user action but the strut's select tag wants it badly cause it returns a list of role ids, and there's no way to automatically map it to the id field of role.
One of the good things in my userAction is that the user-role initialization is now done inside user dao and not on user service. I'm now into providing an edit user function.
*****
Let me call it a day. In theory, we already did more than 80% of the project. But, yes "but", the integration didn't seem to have gone smoothly. The borrowing, and returning, can't be committed to the SVN due to an unknown reason.
I've already created a smooth navigation between login – admin – logout – login – employee etc. First thing tomorrow, we got to make the borrowing and returning fully functional. I also have to do a lot of refactoring still especially in status, author, books, and especially borrowedBooks. And yeah, we are planning to add the log in the services.
2 comments:
Hi, XT. I think it's ok for a DAO to call another DAO. Actually, I think that's actually better, since it avoids code duplication.
Hi, XT. I take back what I just said. I did some research on JDBC best practices. I got great info from the PreciseJava site For performance's sake, I learned that it's best for a DAO not to call another DAO. Why? Because with a single DAO, you can make just one I/O call to the database. With more than one DAO, you need to make two or more calls to the DB. When reading from a database, make sure you fetch all your data use only one SELECT statement, via JOINs. You should also take advantage of batch retrieval by using the setFetchSize method. When writing to the database, make sure to take advantage of batch updates, using the addBatch and executeBatch methods.
Post a Comment