0
680
Vistasestructura 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?
3 Respuestas
Responde la pregunta0
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/setLa 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:
Sin embargo, para su propio propósito, puede decidir completamente cómo administrar los paquetes, los siguientes también son legítimos:
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.
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.
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.dataocom.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.dataocom.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
-