Java servlet 和持久性结构

Question

我有一个java webapp，它有一个servlet doPost，它接受一些json POST。我们称其为“人”。所以它会收到类似 { name: "Joe",age: 35 } 的信息。然后还有一个 Jackson 的数据绑定(bind)类来捕获这个......就像

public class Person {
  public String name;
  public int age;
}

我目前在 Servlet 类中发生了 DB 的事情。就像 servlet 接收请求一样，将其反序列化为 Person 对象，然后获取该结果对象并创建 JDBC 连接并运行插入。构建这个结构的最佳方法是什么？这样可以吗？我觉得持久性应该更多地与对象本身相关，而不是与 servlet 相关。我应该将数据库功能放入 Person 对象中吗？或者创建一些新的“东西”来处理它？<​​/p>

Answer 1

I feel like the persistence should be more linked to the object itself than to the servlet.

两者都不正确，基本上，我们需要正确地对应用程序进行分层，即我们不应该不要混淆前端(用户界面)关注点和业务逻辑，并检查下面有关分层的更多说明网络应用程序。

Should I put the DB functionality into the Person obj? Or create some new "thing" to handle it?

不，您需要单独处理数据访问层，例如使用 DAO(数据访问对象)或存储库层。

一般来说，Web 应用程序架构的工作原理如下:

HTML/JSP -> Servlet 和 Controller 类 -> 服务层 -> DAO 层 -> 数据库

每一层都有其自身的原因，我们不应该混淆这些问题。

现在具体讨论 DAO 层(查看 DAO 模式如何工作)，有各种框架可以使事情变得更容易，ORM(对象关系映射)是您可能感兴趣的概念。仅举几例，流行的ORM框架有Hibernate和 Spring data JPA .

<小时/>

更新:

So, the servlet accepts the request, deserializes the data to some data bind classes that match the JSON schema. Then it passes those to some "service layer" that does some kind of manipulation and generates DAO objects that match the table structures and saves it off?

你已经快到了，唯一缺少的是 DAO 对象是单例类(它们不保存数据，只是提供访问数据库的方法)并且模型/实体 bean 确实用于保存数据。

您可以引用下面的简单示例，假设它正在访问数据库中的 PRODUCT 表:

ProductDAOImpl 类(单个对象):

public class ProductDAOImpl implements ProductDAO { //or ProductRepository

    public boolean save(Product product) {
        //add implementation
    }

    public List<Product> queryProducts() {
        //add implementation
    }

    public Product queryUniqueProduct(String productId) {
        //add implementation
    }

    //etc...any other methods you would like
}

产品类别(来自客户/用户的每个请求一个对象):

public class Product { //It is an Entity class

    private String id;

    private String name;

    private int price;

    //all other fields

    //getters and setters
}

<小时/>

What if you have a mismatch between request and data model?

始终确保表示层 bean 和实体(数据库)模型 bean 应该分开，即，在这两层之间共享 bean 不是一个好的做法，因为一层处理业务逻辑，并且另一个用于用户界面(前端)，两者都应该松散耦合。