Spring、Entity vs Model vs Controllerのパッケージ構造

Question

MVCのモデルまたはエンティティの定義方法を教えてください。私の春のコードのほとんどは彼のようなパッケージstrucureを持っていた

：私は私の見解は、私のコントローラ、私のDAOとDAO

ための「モデル」を持っているが、私はthymeleafを学ぼう http://www.mkyong.com/spring-mvc/spring-mvc-form-handling-example/

とこれが見つから： ない「モデル」パッケージはありませんhttps://github.com/thymeleaf/thymeleafexamples-stsm

、彼はエンティティそれを呼び出す、実体けど..私は思っその後、

...ああ分を待っていますute ... entiyとmodelの定義は何ですか？この質問に似て ： Entity vs Model vs View Model

ので あなたのパッケージのstructreが何であるか、あなたがモデルまたはエンティティそれを呼び出すのですか？ 春のプロジェクトのパッケージ名/構造の例がありますか？

Answer 1

My 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. 

私はスプリングブートアプリケーション用にパッケージをどのように構成するのかを簡単に説明してくれることを願っています。しかし誰もが自分の命名を持つのが好きです。だから一般的にすることは非常に困難です。

Answer 2

Modelは、POJOを表現するためのクラスです。 Entity - DBとの関係があります。

package net.lelyak.edu.entity; 

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

構造は、プロジェクトやチームの慣習に依存します。

は、時には彼らは次のように、一緒に混合されます。

あなたの個人的なプロジェクトの場合は、どのパッケージ構造を従うべきかを完全に決めることができます。ここで

は、私は私の春のトレーニングのためにしたいくつかの方法である：

しかし、あなた自身の目的のために、あなたは完全に次のよう、パッケージを管理する方法を決定することができますも合法です：

主な考え方は、厳密な境界線がないことです。

個人的なプロジェクトについては、それはあなたのために便利でなければなりません。
同じプロジェクトで他の人と共同作業する場合は、一緒に同意する必要があります。私のプロジェクトで

Answer 3

私はDAOsオブジェクト単にdataまたはentityを呼びたいとthatsのは、それらがmodelと呼ばれ、あなたのケースでUI presentationに返されるべきであるオブジェクト。私は古いファッションmodel用語の冗長化を行いthymeleaf +春のブートを使用して、すでに長い時間の間にそれ主な理由のをやってる：

• com.company.appName.dataまたは
• com.company.appName.presentation

しかし、の場合com.company.appName.entityより複雑な構造を持つ大規模なプロジェクトのビジネスロジックと一緒に置くのに良い時々presentationオブジェ：

• com.company.appName.data又はcom.company.appName.entity
• com.company.appName.account
  • com.company.appName.account.service - ビジネスロジック
  • com.company.appName.account.presentation
  - UIデータは