Is my idea correct?
How are Java Database Access Layer usually implemented? I am thinking I have a class DBAL which has functions like
- save(Object obj)
- delete(Object obj)
- findOne(String type, String column, String value)
- findAll(String type, String column, String value)
save and delete will accept domain object classes eg. Product, User … then perform the respective actions accordingly
findOne and findAll will accept a type which corresponds to the table name, then column and value used for the WHERE clause. Very simplistic, but I am wondering if the idea is correct?
Usually I see many sites haveing DAO but won’t ProductDAO and UserDAO be very similar? I could probably merge them into 1 class DBAL?
Simulating ORM
Comming from a ORM background. I am wondering how will ResultSet.getObject work, will it work like ORM where I query the User table and I can get back a List<User> for example?
There are many ways to implement a Database Access Layer in Java, and the same patterns apply in other languages as well. The simplest form would be a Table Data Gateway. In this pattern there is a gateway instance per database table. Other patters for DAL are Table Row Gateway in which there is a gateway instance per database row in a table. Active Record, where a domain object knows how to talk to the database itself. Data Mapper where data is moved between domain objects and the database while keeping them independent of each other and the mapper itself.
There are various pros and cons with each of these approaches. Try to look up the patterns I mentioned and see what would work best for your application.
The main reason people subclass their base DAO (TDG, TRG, what have you) is to provide an explicit, distinct, type safe interface per domain object type + it makes it easier for clients to locate the right data access function they need in order to implement a use case. Code that is the same is abstracted in the base class…
If you are in the start phase of the application I would recommend that you use a tool for dealing with data access (like Hibernate for example). These tools are very generic and there are a million problems with them but at least you can focus on getting you business logic right first and then worry about these problems that are outside of you applications domain. If it turns out that there is a problem after all and it looks like your software is a success, you can go ahead and work on data access to improve performance or an other headache that the tool you choose is giving you. I am only saying this because it is rather difficult to make a good homegrown data access solution and it will take up a lot of your time. Think about concurrency problems, mapping from database id to memory instance(s!), etc. etc.
As for your question about ResultSet. No, getObject will get you the value of the designated column in the current row of this ResultSet object as an Object. So you have to do the cast yourself and that is also why it is a good idea to have a Factory from ResultSet for your domain objects if you go down this path.
This is a huge topic and I am sorry if I can’t go into all of the patterns into more detail. I have also work to do myself 🙂 If you decide to make your own instead of going with a “standard” tool, I would be happy to answer more of your questions after you have figured out which of the patterns I mention here would best suite your needs.
Regards.