• 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
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
Sheriffs:
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
Bartenders:
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

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?
 
Saloon Keeper
Posts: 2086
76
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.
 
Bartender
Posts: 20124
103
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.
 
Your mother was a hamster and your father was a tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
https://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!