Spring中的包结构，Entity vs Model vs Controller

问题描述 投票：0回答：4

MVC 中如何定义模型或实体？

我的大多数 Spring 代码都有像他这样的包结构： http://www.mkyong.com/spring-mvc/spring-mvc-form-handling-example/

我有我的视图、我的控制器、我的 dao 和 dao 的“模型”

但我尝试学习百里香并发现了这个： https://github.com/thymeleaf/thymeleafexamples-stsm

没有“模型”包，他称之为实体，它是一个实体但是..

然后我想...哦等等...实体和模型的定义是什么？ 类似于这个问题： 实体 vs 模型 vs 视图模型

所以 你的包结构是什么，你称之为模型还是实体？ 你有你的 spring 项目的包名称/结构的示例吗？

java spring spring-mvc spring-boot
4个回答
14
投票

从字面上看，

Model
是代表POJO的类。 
Entity
- 与 DB 相关。

有时它们会混合在一起，例如：

package net.lelyak.edu.entity;

@Entity
public class User extends BaseEntity {
// fields + get/set

结构取决于您的项目或团队的惯例。

如果这是您的个人项目，您可以完全决定要遵循哪种包结构。

这是我为春季训练所做的一些方法：

enter image description here

但是，为了您自己的目的，您可以完全决定如何管理包，以下也是合法的：

enter image description here

主要思想是没有严格的边界。

对于个人项目，它必须为您带来便利。
当您与其他人合作同一项目时，您必须共同同意。

7
投票

我的 Spring 项目大多数都有如下所示的包结构。这个结构是我的 

dao
、
services
、
implementations
、
view
和 
util
的基础结构。当然，结构可以改变，这一切都取决于你要开发什么。 

com.companyName.appName.config -> 
I use config for my classes which are annotated with @Configuration.

com.companyName.appName.dao.model -> 
I use dao.model for all my entities from the DB.

com.companyName.appName.dao.repository -> 
I use dao.repository for all the repositories used with spring-data-jpa.

com.companyName.appName.dao.repository.impl -> 
I use dao.repository.impl for all customized implementations of repositories. 
For example to autowire the entityManager.

com.companyName.appName.service -> 
I use service for all my service interfaces

com.companyName.appName.service.impl -> 
I use service.impl for all my implementations of services

com.companyName.appName.controller -> 
I use controller for all my controllers.

com.companyName.appName.view.model -> 
I use view.model for all my frontend specific models which are no enitites.

com.companyName.appName.view.form -> 
I use view.form for all my frontend specific forms which has to be submitted and validated.

com.companyName.appName.util -> 
I use util for utility stuff.

我希望这能让您简要概述我如何为 spring-boot 应用程序构建我的包。但每个人都喜欢有自己的命名。所以很难让它通用。

1
投票

在我的项目中，我喜欢将 

DAOs
对象简单地称为 
data
或 
entity
，并且应该返回到 UI 的对象 
presentation
在您的情况下，它们被称为 
model
。我这样做主要是因为很长一段时间以来已经使用了thymeleaf + Spring-Boot，这使得旧时尚
model
术语变得多余：

  • com.company.appName.data
    或 
    com.company.appName.entity
  • com.company.appName.presentation

但在结构更复杂的大型项目中，有时

presentation
对象很适合与业务逻辑放在一起：

  • com.company.appName.data
    或 
    com.company.appName.entity
  • com.company.appName.account
    • com.company.appName.account.service
      - 业务逻辑
    • com.company.appName.account.presentation
      - UI 数据对象
0
投票

在软件开发的背景下，术语“模型”和“实体”有时可以互换使用，当我第一次遇到这些术语时，这让我感到困惑。

实体通常是指代表数据库中的表的类。实体通常用 

@Entity
进行注释（例如 JPA 的 @Entity 注释），用于将数据库表映射到 Java 类。实体通常用于应用程序的数据访问层。

另一方面，

模型是一个更广泛的术语，指的是代表应用程序业务领域中的概念或对象的类。模型可以是一个实体，但也可以是一个类，代表不直接映射到数据库表的业务概念。 换句话说，所有实体都是模型，但并非所有模型都是实体

。

为了增加混乱，遗留项目使用子包和类名后缀，如 DTO、VO、DAO 等，但这些现在被认为是“老派”，主导术语已成为“域”...请参阅以下有关首选的文章构建项目的方法：按功能打包，而不是分层

如果您遵循本文的建议，您最终将得到以下结构：

com.me.myapp ├── doctor │ ├── DoctorAction.java │ ├── Doctor.java │ ├── DoctorDAO.java │ ├── DoctorService.java │ └── DoctorController.java ├── patient │ ├── PatientAction.java │ ├── Patient.java │ ├── PatientDAO.java │ ├── PatientService.java │ └── PatientController.java ├── prescription │ ├── PrescriptionAction.java │ ├── Prescription.java │ ├── PrescriptionDAO.java │ ├── PrescriptionService.java │ └── PrescriptionController.java ├── report │ ├── ReportAction.java │ ├── Report.java │ ├── ReportDAO.java │ ├── ReportService.java │ └── ReportController.java ├── security │ ├── SecurityAction.java │ ├── Security.java │ ├── SecurityDAO.java │ ├── SecurityService.java │ └── SecurityController.java ├── util │ └── MyUtil.java └── MyApplication.java 




    

    


  

  

    
最新问题


  





  

    © www.soinside.com 2019 - 2024. All rights reserved.