编写数据访问对象 (DAO) 的最佳方法是什么?
我正在尝试用Java 编写一个用户身份验证系统。所以我写了一些 DAO 类。首先,我编写了一个名为 Persistence 的抽象类。它负责保存一些公共属性。并编写了一个名为 User 的类,扩展了 Persistence 类。这些类是 -
public abstract class Persistance {
private Date createdDate;
private Date lastUpdatedDate;
private long version;
private boolean isDeleted;
//getter and setters
}
以及用户类
public class User extends Persistance{
private String username;
private String password;
private String passwordConfired;
// getters and setters
}
我的问题是 - 编写变量名的最佳方法是什么,哪个是好的,createdDate或dateCreated,deleted或isDeleted等。
这种方法是否可以或者是否有更好的方法? 以及如何实现数据版本控制?
I was trying to write a user authentication system in Java. So I wrote some DAO class. First I did write a class named Persistence which is abstract. It is responsible for holding some common attributes. And wrote a class named User extending Persistence class. Those classes are –
public abstract class Persistance {
private Date createdDate;
private Date lastUpdatedDate;
private long version;
private boolean isDeleted;
//getter and setters
}
and the user class
public class User extends Persistance{
private String username;
private String password;
private String passwordConfired;
// getters and setters
}
My questions are- what is the best way to write variable name, which one is good, createdDate or dateCreated, deleted or isDeleted etc.
And is this approach is okay or is there more good approach ?
And how to implement data versioning?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
要编写 DAO,通常需要创建一个定义 DAO 行为的接口。
然后创建实际的实现
这样做的优点是:
1) 因为您定义了一个接口,所以对于任何测试框架来说,模拟 DAO 都很容易
2) 行为与实现无关——您的 DAOImpl 可以使用 jdbc、hibernate,无论什么。您
的 Persistance 类实际上是所有实体的基类——即保存的所有类实例,您想要在一个地方表示一些公共字段的地方。这是一个很好的实践——我不会调用类
Persistance
,像BaseEntity
这样的类更好(恕我直言)。确保有 javadoc 解释该类的用途。对于变量名,只要它们有意义并且描述了它们的用途,那就很好。
所以
dateCreated
或createdDate
都可以;他们都明白了这个想法。To write a DAO, typically you create an interface that defines the behavior of the DAO.
and then you create the actual implementation
The advantages of this are:
1) Because you define an interface, mocking DAOs is easy for any testing framework
2) The behavior is not tied to an implementation -- your DAOImpl could use jdbc, hibernate, whatever
Your
Persistance
class is really a base class for all entities -- i.e. all classes instances of which get saved, where you want to represent some common fields in one place. This is a good practice -- I wouldn't call the classPersistance
, something likeBaseEntity
is better (IMHO). Be sure to have javadocs that explain the purpose of the class.With respect to variable names, as long as they make sense and describe what they are for, its good.
so
dateCreated
orcreatedDate
are both fine; they both get the idea across.您将 DAO(数据访问对象)和 VO(值对象)(也称为 DTO(数据传输对象))混合在同一个类中。
使用 DAO 行为接口的示例(blammy 和 kpow 可能是 web 服务、oracle 数据库、mysql 数据库、hibernate 或任何有意义的东西):
示例 VO:
我更喜欢使用 ID 而不是 VO 对象来标识删除的目标。另外,更新可能会将用户 ID“smackdown”标识的目标更改为用户 ID“smackup”,因此我通常会传递 id 和 VO。
You are mixing a DAO (data access object) and a VO (value object) - also known as a DTO (data transfer object) - in the same class.
Example using an interface for DAO behavior (blammy and kpow might be webservice, oracle database, mysql database, hibernate, or anything meaningful):
Example VO:
I prefer to identify the target of the delete using an ID instead of a VO object. Also, it is possible that an update will change the target identified by user ID "smackdown" to have user ID "smackup", so I generally pass an id and a VO.
一个好的方法是使用 JPA 及其所有功能,此 教程真的很有帮助。
它解释了如何使用@PrePersist和@PreUpdate注释来设置创建和更新时间戳。 @Version 注解支持乐观锁定。
A good approach would be to use JPA with all of its features, this tutorial was really helpful.
It explains how to use the @PrePersist and @PreUpdate annotations for setting create and update timestamps. Optimistic locking is supported by the @Version annotation.
或dateCreated是非常主观的。在数据库中,我主要看到的是createdDate。在deleted和isDeleted之间,我更喜欢(同样是主观的)删除。我认为getter方法可以命名为isDeleted()。
createdDate or dateCreated is very subjective. In databases, I have mostly seen createdDate though. Between deleted and isDeleted, I prefer (again subjective) deleted. I think the getter method can be named isDeleted().