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?
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.
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.
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.
An IDE is no substitute for an Intelligent Developer.
posted 2 months ago
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: