DAO架构的必要性是什么
用Java编程时是否总是需要根据DAO架构来编码？如果是的话，使用它有什么好处？
我正在做一个项目，其类图如下所示。这样做有什么缺点？
实体类：
private void fillSONumber() {
try {
ZnAlSalesOrder o = new ZnAlSalesOrder();
ArrayList a = o.getPendingSalesOrderIDs();
for (int i = 0; i < a.size(); i++) {
cmbSoNo.addItem(a.get(i));
}
o.close();
} catch (Terminated ex) {
}
}
EntityTable 类 示例：
public ResultSet select(String fields, String selection) {
db = new Database();
db.select("SELECT " + fields + " FROM " + name + " WHERE " + selection);
return rs = db.rs;
}
由数据库类进行连接建立和销毁。
When programming in Java is it always necessary to code according to the DAO architecture? If so what are advantages of using it?
I'm doing a project which has a class diagram like below. what are the disadvantages of this?
Entity Class:
private void fillSONumber() {
try {
ZnAlSalesOrder o = new ZnAlSalesOrder();
ArrayList a = o.getPendingSalesOrderIDs();
for (int i = 0; i < a.size(); i++) {
cmbSoNo.addItem(a.get(i));
}
o.close();
} catch (Terminated ex) {
}
}
EntityTable Class Example:
public ResultSet select(String fields, String selection) {
db = new Database();
db.select("SELECT " + fields + " FROM " + name + " WHERE " + selection);
return rs = db.rs;
}
and the database class do the connection establishment and destroying.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
DAO 是一种常见的最佳实践，过去一直有效且干净。优点是，当新开发人员开始项目时，他很可能已经熟悉这种设计。对于任何模式来说，最重要的事情就是保持其解耦。这非常重要，因为稍后您应该能够用其他实现替换 DAO，而不会影响其余代码。
对我来说这是有道理的。我的问题是，你是唯一使用它的人吗？如果是这样，那么您需要所有这些接口吗？如果您要将实现传递给其他人，接口就很重要。就像 API 一样。稍后它可能会更改为另一个子类。但如果你完全控制你的设计，我认为你不应该无缘无故地创建臃肿的界面。
最后，您的代码看起来很好，除了
o.close();为什么客户端需要调用 close？每个 DAO 函数都应该足够智能，能够打开和关闭连接。数据库对于您的 bean 应该是透明的。我认为不需要进行关闭。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.
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.DAO 模式的目的是将您尝试访问的数据与其存储方式分开。
例如，您可以创建一个指定许多方法的 DAO，然后针对 MySQL 实施这些方法。如果您决定需要迁移到 MSSQL 或 Oracle，则只需更改实现，而不是可以在代码中的许多不同位置使用的接口。
没有必要这样做，但它可能是一个好主意，可以使将来的更改更容易并保持代码解耦。
至于您的设计，基本布局很好，但我建议您不要使用像您这样的通用选择方法。您基本上只是创建了另一个抽象层，其中可能会出现问题，而没有任何额外的好处。
它对于简单查询来说效果很好，但如果您需要进行任何联接，您很快就会得到大量针对不同联接类型的方法。
最好只为需要访问的每种数据类型编写 SQL，并创建一个返回所需数据类型的方法。这减少了耦合，并允许您根据需要更改实现。
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.
数据访问对象 (DAO) 是指 CRUD（创建、读取、更新和删除）方法。您的 EntityTable 类示例更适合放在 Gateway 对象中，该对象封装了针对表中多行数据的操作。因此，这种方法对于两种类型的对象都有一些优点和缺点：
DAO 提供了一种方便的方法来抽象保存数据，特别是这样您就不需要区分插入和更新。
网关允许您构建专门的查询。例如，假设您有一个搜索结果，需要对数据进行分页。除了任何条件之外，网关方法还可以将开始行和结束行作为参数，并仅返回该窗口的记录集。
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 就像一个协议或规则，遵循它以某种方式存储您的数据。在 DAO 中，我们有四个 Java 类，例如 Connection、Normal Bean、Interface 和 Service 类。这些所有类都有各自的工作。就像在 Connection 类中，您为数据库连接建立连接一样，在 Normal Bean 中，您拥有所需的所有属性，在接口中，您只有方法声明，所有业务逻辑都驻留在服务类中。
因此，预先定义了哪些工作将在哪里完成。因此，任何刚接触该项目的人都可以轻松了解该项目的流程。
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.