What is the necessity of DAO Architecture

こ雲淡風輕ζ 提交于 2019-12-03 19:37:37

The purpose of a DAO pattern is to separate what data you are trying to access from how it is stored.

For example, you could create a DAO that specifies a number of methods that you then implement against MySQL. If you ever decide you need to move to MSSQL or Oracle, you only need to change the implementation, not the interface that could be used in a number of different places in your code.

It is not necessary to do this, but it can be a good idea to make future changes easier and keep your code decoupled.

As for your design, the basic layout is fine, but I would recommend against a generic select method like you have. You are basically just creating another layer of abstraction where something could go wrong without any extra benefit.

It will work well for simple queries, but if you need to do any joins, you will quickly end up with a large mess of methods for different join types.

It is better to just write your SQL for each type of data you need to access and create a method that returns the type of data you want. This reduces your coupling and allows you to change your implementation if needed.

When programming in Java is it always necessary to code according to the DAO architecture? If so what are advantages of using it?

DAO is a common best practice that has worked in the past and is clean. The advantages are that when a new developer starts on the project then most likely he is already familiar with this design. The most important thing of doing with any pattern is to keep it decoupled. This is very important because at a later point you should be able to replace DAO with some other implementation without affecting the rest of your code.

I'm doing a project which has a class diagram like below. what are the disadvantages of this?

To me that makes sense. My question is, are you the only person using it. If so, do you need all those interfaces then? Interfaces are important if you are passing your implementation to someone else. Like an API. And later it might change to another subclass. But if you have full control of your design, I don't think you should create bloated interfaces for nothing.

Finally, your code looks fine except o.close(); Why does the client need to call close? Each of the DAO functions should be smart enough to open the connection and close it. The database should be transparent to your beans. Having to do a close is not needed in my opinion.

Data Access Objects (DAOs) mean CRUD (Create, Read, Update and Delete) methods. Your EntityTable class example more appropriately fits in a Gateway object, which encapsulates actions against multiple rows of data in a table. So some pros and cons of this approach for both type of object:

DAOs provide a convenient means to abstract saving data in particular so you don't need to make a distinction between insert and update.

Gateways allow you to build specialized queries. For instance, say you have a search result where you need to paginate the data. A gateway method might take start and end row as arguments, in addition to any criteria, and return a record set of only that window.

DAO is like a protocol or rule which followed to be stored your data in a manner. In DAO we have four Java Classes like Connection,Normal Bean,Interface,and Service Classes. These all classes has their own work separately.Like in Connection class you make a connection for database connectivity,in Normal Bean you have all the attributes which are you need,In interface you have only method declaration , all business logics are reside in service class. So it is predifine that what work will be done where.So any person which is new for the project can be understand flow of the project easily.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!