• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Devaka Cooray
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Tim Holloway
  • Claude Moore
  • Stephan van Hulst
Bartenders:
  • Winston Gutkowski
  • Carey Brown
  • Frits Walraven

DAO interface, what to implement?  RSS feed

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys, I'm building DAO interface for a few classes. Every single class (users, exercises etc. ) connects with same MySQL database. I'm wondering what else besides CRUD I should implement in the interface. Maybe: Connection, PreparedStatement? Should I code whole CRUD methods in DAO interface, or just simple: void save(T t); void update (T t); etc. , and then override all methods for each classDAO separately?
 
Bartender
Posts: 2166
92
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bart Wtoras wrote:... I should implement in the interface. Maybe: Connection, PreparedStatement? Should I code whole CRUD methods in DAO interface...


An interface is a set of methods, variables declared in an interface are final.
The reason why a Database layer is separated from your application is that it can change in the future. You may switch from MySql to Oracle or even an in-memory or a file-based persistence implementation.

Your methods maybe like this :

saveUser(User user);
fetchUserById(Long userId);
updateUser(User user);

Any class implementing this interface will provide the definitions for all these methods and your service layer need not know about the implementation specifics. Connections, Prepared statements, etc.. should ideally not be exposed to your service layer.
 
Saloon Keeper
Posts: 20510
115
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I use a 2-tier approach myself.

Applications frequently interact with a database using a related set of records in a single transaction. For example, you might pull all the employees from a department in a company. This makes a "working set" and so rather than make the application code directly yank in all the different types of records using DAOs, I use a persistence service layer. Working set objects in this layer have live access to the database (more about this in a minute), and do  work within a single database transaction. So this is a business-oriented data access layer.

Underneath that layer is my DAO layer where the DAO objects themselves live. I mentioned that the service layer has "live access" to the database, but what I actually mean is that the service layer does its database I/O by using the DAOs in the DAO layer.

The DAOs are pretty much just finder/CRUD objects. Each DAO is responsible for access to a single table, or in some cases, a parent/child table set. There's no sense of business process here, just raw I/O. The transactional context is inherited from the service method that uses the DAOs. Application logic always talks to service layer objects and methods, never to DAO layer methods. In the relatively rare case where the application logic just needs basic DAO functions, I write a service object that acts as a fa├žade for that DAO. It may be a little more work and overhead, but it pays for itself because it's clean and predictable - you never have to worry about which layer you're getting data from.

I'm generally using the Java Persistence Architecture (JPA), which works very well with this arrangement. I'm also generally using an Inversion of Control (IoC) injection framework, and that handles plugging in the EntityManager connections for each DAO.

If you're doing raw JDBC, you can do something similar, although in truth, if you need that much structure, you'll get more maintainable code and a generally more efficient application by using JPA or something like that.
 
Bart Wtoras
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Currently I'm doing raw JDBC, but in the next module of java dev. course I will have Hibernate.
Anyway thank you guys for your time, now it's crystal clear.
 
If you open the box, you will find Heisenberg strangling Shrodenger's cat. And waving this tiny ad:
Become a Java guru with IntelliJ IDEA
https://www.jetbrains.com/idea/
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!