CODEWITHSUNDEEP
javaspringspring-mvcspring-boot
w3Charlie
w3Charlie

Reputation: 133

package structure in Spring,Entity vs Model vs Controller

how do you define what is model or entity in MVC?

most of my Spring codes had package strucure like his: http://www.mkyong.com/spring-mvc/spring-mvc-form-handling-example/

I have my view, my controller, my dao and "the model" for the dao

but I try to learn thymeleaf and found this: https://github.com/thymeleaf/thymeleafexamples-stsm

there is no "model"package, he call it entity, it is an entity but..

then I thought...oh wait a minute...what is the definition of entiy and model? similar to this question: Entity vs Model vs View Model

so what is your package structre, do you call it model or entity? do you have maybe examples of the packagenames/structure of your spring projects?

Upvotes: 11

Views: 21840

Answers (4)

sfinja
sfinja

Reputation: 756

The terms "model" and "entity" are sometimes used interchangeably, which confused me when I first encountered those terms.

An entity refers to a class that represents a table in a database. Entities are annotated with @Entity (e.g., JPA's @Entity annotation) and are used to map database tables to Java classes. They are used in the data access layer of an application.

A model, on the other hand, is a broader term that refers to a class that represents a concept or an object in the business domain of the application. A model can be an entity, but it can also be a class that represents a business concept that is not directly mapped to a database table.

In other words, all entities are models, but not all models are entities.

To add the confusion, legacy projects use subpackages and classname suffixes like DTO, VO, DAO, etc. but these are considered now "old school" and the dominant term has become "domain"... See the following article on the preferred approach to structuring your project: Package by feature, not layer

If your follow the article's recommendation, you will end up with the following structure:

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

Upvotes: 2

Lugaru
Lugaru

Reputation: 1460

In my projects I like to call DAOs objects simply data or entity and objects thats should be returned to the UI presentation in your case they are called model. I'm doing it mainly because of during long time already using thymeleaf + Spring-Boot which makes old fashion model terminology redundant:

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

But in a case of big projects with more complex structure sometimes presentation objets good to place together with business logic:

  • com.company.appName.data or com.company.appName.entity
  • com.company.appName.account
    • com.company.appName.account.service - business logic
    • com.company.appName.account.presentation - UI data objects

Upvotes: 1

catch32
catch32

Reputation: 18582

Literally, a Model is a class for representing POJO. Entity - has relation to DB.

Sometimes they are mixed together, like:

package net.lelyak.edu.entity;

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

The structure depends on a convention of your project or team.

If it is your personal project you can fully decide which package structure you want to follow.

Here is some way which I did for my spring training:

enter image description here

However, for your own purpose, you can fully decide how to manage packages, following are also legit:

enter image description here

The main idea is that no strict borders for it.

For the personal project, it has to be a convenience for you.
When you collaborating with others on the same project, you have to agree on it together.

Upvotes: 14

Patrick
Patrick

Reputation: 12734

My Spring projects most have a package structure like below. This structure is my base structure for dao, services, implementations, view and util. Sure the structure can change and all that depends on what you have to develop. 

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.

I hope this gives you a short overview how I structure my packages for spring-boot applications. But everybody like to have its own naming. So its very difficult to make it general.

Upvotes: 7

Related Questions