编写数据访问对象 (DAO) 的最佳方法是什么?

发布于 2024-12-06 07:42:56 字数 726 浏览 2 评论 0原文

我正在尝试用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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

小鸟爱天空丶 2024-12-13 07:42:56

要编写 DAO,通常需要创建一个定义 DAO 行为的接口。

interface MyObjDao {

    public int save(MyObj myObj);

    public void delete (MyObj myObj);

    // as many methods as you need for data acess

}

然后创建实际的实现

class MyObjDaoImpl implements MyObjDao {
    // implement methods here

}

这样做的优点是:

1) 因为您定义了一个接口,所以对于任何测试框架来说,模拟 DAO 都很容易
2) 行为与实现无关——您的 DAOImpl 可以使用 jdbc、hibernate,无论什么。您

的 Persistance 类实际上是所有实体的基类——即保存的所有类实例,您想要在一个地方表示一些公共字段的地方。这是一个很好的实践——我不会调用类Persistance,像BaseEntity这样的类更好(恕我直言)。确保有 javadoc 解释该类的用途。

对于变量名,只要它们有意义并且描述了它们的用途,那就很好。

所以 dateCreatedcreatedDate 都可以;他们都明白了这个想法。

To write a DAO, typically you create an interface that defines the behavior of the DAO.

interface MyObjDao {

    public int save(MyObj myObj);

    public void delete (MyObj myObj);

    // as many methods as you need for data acess

}

and then you create the actual implementation

class MyObjDaoImpl implements MyObjDao {
    // implement methods here

}

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 class Persistance, something like BaseEntity 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 or createdDate are both fine; they both get the idea across.

明明#如月 2024-12-13 07:42:56

您将 DAO(数据访问对象)和 VO(值对象)(也称为 DTO(数据传输对象))混合在同一个类中。

使用 DAO 行为接口的示例(blammy 和 kpow 可能是 web 服务、oracle 数据库、mysql 数据库、hibernate 或任何有意义的东西):

public interface UserDTO
{
    boolean deleteUser(String userId);
    UserVO readUser(String userId);
    void updateUser(String userId, UserVO newValues);
}

package blah.blammy;
public class UserDTOImpl implements UserDTO
{
  ... implement it based on blammy.
}

package blah.kpow;
public class UserDTOImpl implements UserDTO
{
  ... implement it based on kpow.
}

示例 VO:


public class UserVO
{
    String firstName;
    String lastName;
    String middleInitial;

    ... getters and setters.
}

我更喜欢使用 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):

public interface UserDTO
{
    boolean deleteUser(String userId);
    UserVO readUser(String userId);
    void updateUser(String userId, UserVO newValues);
}

package blah.blammy;
public class UserDTOImpl implements UserDTO
{
  ... implement it based on blammy.
}

package blah.kpow;
public class UserDTOImpl implements UserDTO
{
  ... implement it based on kpow.
}

Example VO:


public class UserVO
{
    String firstName;
    String lastName;
    String middleInitial;

    ... getters and setters.
}

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.

吹泡泡o 2024-12-13 07:42:56

一个好的方法是使用 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.

三五鸿雁 2024-12-13 07:42:56

我的问题是 - 编写变量名称的最佳方式是什么?
一个是好的,createdDate 或 dateCreated,deleted 或 isDeleted 等。

或dateCreated是非常主观的。在数据库中,我主要看到的是createdDate。在deleted和isDeleted之间,我更喜欢(同样是主观的)删除。我认为getter方法可以命名为isDeleted()。

My questions are- what is the best way to write variable name, which
one is good, createdDate or dateCreated, deleted or isDeleted etc.

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().

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文