Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

822
Views
estructura del paquete en Spring, Entidad vs Modelo vs Controlador

¿Cómo se define qué es modelo o entidad en MVC?

la mayoría de mis códigos Spring tenían una estructura de paquetes como la suya: http://www.mkyong.com/spring-mvc/spring-mvc-form-handling-example/

Tengo mi vista, mi controlador, mi dao y "el modelo" para el dao

pero trato de aprender thymeleaf y encontré esto: https://github.com/thymeleaf/thymeleafexamples-stsm

no hay un paquete "modelo", él lo llama entidad, es una entidad pero ...

entonces pensé... oh espera un minuto... ¿cuál es la definición de entidad y modelo? similar a esta pregunta: Entidad vs Modelo vs Modelo de vista

Entonces, ¿cuál es la estructura de su paquete? ¿Lo llama modelo o entidad? ¿Tiene quizás ejemplos de los nombres de paquetes/estructura de sus proyectos de primavera?

over 4 years ago · Santiago Trujillo
3 answers
Answer question

0

Literalmente, un Model es una clase para representar POJO. Entity : tiene relación con DB.

A veces se mezclan, como:

 package net.lelyak.edu.entity; @Entity public class User extends BaseEntity { // fields + get/set

La estructura depende de una convención de su proyecto o equipo.

Si es su proyecto personal, puede decidir completamente qué estructura de paquete desea seguir.

Aquí hay algo que hice para mi entrenamiento de primavera:

ingrese la descripción de la imagen aquí

Sin embargo, para su propio propósito, puede decidir completamente cómo administrar los paquetes, los siguientes también son legítimos:

ingrese la descripción de la imagen aquí

La idea principal es que no haya fronteras estrictas para ello.

Para el proyecto personal, tiene que ser una comodidad para ti.
Cuando colaboras con otros en el mismo proyecto, tienes que acordarlo juntos.

over 4 years ago · Santiago Trujillo Report

0

La mayoría de mis proyectos de Spring tienen una estructura de paquete como la siguiente. Esta estructura es mi estructura base para dao , services , implementations , view y util . Seguro que la estructura puede cambiar y todo eso depende de lo que tengas que desarrollar.

 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.

Espero que esto le brinde una breve descripción general de cómo estructuro mis paquetes para aplicaciones Spring-Boot. Pero a todo el mundo le gusta tener su propio nombre. Así que es muy difícil hacerlo general.

over 4 years ago · Santiago Trujillo Report

0

En mis proyectos, me gusta llamar a los objetos DAOs simplemente data o entity y los objetos que deben devolverse a la presentation de la interfaz de usuario en su caso se llaman model . Lo hago principalmente porque durante mucho tiempo ya he usado thymeleaf + Spring-Boot, lo que hace que la terminología del model antiguo sea redundante:

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

Pero en el caso de grandes proyectos con una estructura más compleja, a veces los objetos de presentation son buenos para colocarlos junto con la lógica empresarial:

  • com.company.appName.data o com.company.appName.entity
  • com.company.appName.account
    • com.company.appName.account.service - lógica empresarial
    • com.company.appName.account.presentation : objetos de datos de la interfaz de usuario
over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!