# DAO for happenings registration website

As a learn-by-doing project to learn Java webapps, I'm creating a website for registering and displaying happenings using JSP/Servlets, Apache Tomcat server, JDBC and a MySQL database.

I use JSP for views, Servlets for controller functionality and business logic, and I've created ONE DBManager.java class (my only DAO) to abstract SQL statements from my Servlets and JSPs. In my Servlets, I use the DBManager class by declaring a new instance and calling its public methods.

For instance:

DBManager dbm = new DBManager();
Boolean userIsUpdated = dbm.updateUserInDB(user);


My DAO looks briefly like this:

public class DBManager {

final String DATABASE_URL = "NOPE, I won't give you this one ;)";
Connection connection = null;
PreparedStatement pstmt = null;

public DBManager() {
//Nothing in constructor yet.
}

public ArrayList<Happening> getAllActivatedHappenings() {
}

}

public User insertUserIntoDB(User user) {
}

public boolean updateUserInDB(User user) {
}

public boolean insertHappeningIntoDB(Happening happening) {
}

public boolean deleteHappeningFromDB(int happeningId, int userId) {
}

public ArrayList<HappeningType> getAllHappeningTypes() {
}

public ArrayList<Happening> getAllHappeningsByUserId(int userid) {
}

public byte[] getPhotoByHappeningId(int happeningId, String imageType) {
}

public Map<Integer, String> getCountiesMap() {
}

public Boolean userIsHappeningOwner(int userId, int happeningId) {
}

public Happening getHappeningByHappeningId(int happeningId) {
}

public boolean updateHappening(Happening happeningDummy, String updateImage) {
}

public ArrayList<Happening> getFilteredActivatedHappenings(HttpServletRequest request) {
}

public boolean activateHappening(int happeningId) {
}

}

public User getUserByEmail(String email) {
}
}


As you can see, my DAO handles quite a lot of different transfer objects (happenings, users, cities, happening types etc.). Should I break this DAO into several smaller DAO classes (like HappeningDAO, UserDAO, etc.)? Any other reasons for doing this than readability?

Also, is this approach thread-safe as long as I declare a new instance of DBManager within my doGet/doPost methods in the servlets?

Just a quick note: ArrayList<...> return types should be simply List<...>. See: Effective Java, 2nd edition, Item 52: Refer to objects by their interfaces

I would use an Object-Relational Map package, such as Hibernate. Almost all of the object specific logic could then be moved to the DAO objects themselves and the DBManager would only have to worry about database transactions - fetching, updating, inserting, and deleting objects.

Even if you do not choose to use such a package, the logic for each object type should still be moved somewhere else - either to the DAO class itself or to some kind of DB helper object that would translate high level actions into low level DB calls/SQL.

Yes, I would split the one DAO object onto several separated one, because yours is going to grow and soon you'll realise that it has become a mess.

Unless it is a professional project, I suggest, for study before beginning a long work, you look before in Quick download db4o (you can load 8.1)

Inside zip file, you have doc directory with a tutorial for learn, and a reference for browser with index and search tool (very complete and uptodate doc).

First work with EmbeddedObjectContainer, have a look to

• SODA query,
• Transparent Activation and Transparent Persistence to understand OODB powerfulness,
• After you can configure a Server.
• Don't forget OME the integrated manager, it can be a model for your project.
• You will forget 'select/join' SQL burden for a light/fast 'choose and navigate' in OODB.
• Do not imagine table for data but graph : some fields are ActivatableArry[Set|List|..] linking instances, as internal indexes.

Have in mind that db4o can be migrated to Versant professional for huge databases.

If you are aware, this will take few time, and with a couple of hour you will be able to see OODB functionnality, then you will be able to test some tools.

You can try to work with JSON (Vaadin) for Web with Tomcat. If you want to go further look Jease to avoid some pitfalls, and more stressed web conections

All those tools are Eclipse compatible

So you will be able if it is worth to continue in your first way or choose another perspective, but SGBDR will give you more problems, more works, more issues, and SQL is not powerfull for OO code, even if Hibernate is powerfull it is complicated, SQL have no future for OO languages, and JSON is more now mature.

• I wouldn't necessarily agree that Hibernate is complicated. Yes, there are many features and it can do some complicated things, but if you ignore most of it and just stick to what you need, it can be very simple - especially with JPA annotations. Nor do I necessarily agree that OODBs are the answer for every problem. Yes, they are good answers for many problems, but no solution is universally best. Aug 9 '12 at 14:37
• @Donald.McLean - As SGBDR DBA (Sybase/Oracle), I can understand your point of view. - Yes OODB are not universal, but they are now mature ... I can say that I'll never more code request/join. For me SQL is dead (even if many API work with it [as on Cobol], and many peoples will be paid for it). So, I just gave new orientations to look inside, before coding a new project. Thanks for attention you paid for my post.
– cl-r
Aug 9 '12 at 15:31