EntityとFormを兼務していいの？

Question

簡単なCRUD操作ができるWebアプリ（ポートフォリオ）を作成しております。
ごちゃごちゃ書いていますが、最終的にはEntityアノテーションを積極的に使っていいのか、が聞きたいです。
そう思った経緯が以下に書いてありますが、文字が多くなってしまい、あまり上手にまとめられなかったので結論だけいただくような回答でもありがたいです。

プロジェクトの構成について考えております。

//プロジェクトの構成を考え中(src)
□app
┗controller    //パスを受け取り様々な制御するよ
┗form          //フォーム情報の受け渡し
□domain
┗entity        //データ(テーブル）
┗repository   //DBからデータをとるよ
┗service      //リポジトリのメソッドを使ってCRUDしたりするよ
□utils         //共通
MainController.java//メイン
WebSecurityConfig.java//認証だよ

EntityアノテーションをつけるとEntityクラスとして認識するということでテーブルの名前なんかもつけられてテーブルと連携できるワケですが、もし、Form情報とEntityクラスの作りが全く同じもしくは類似している場合、Entityクラスをフォーム情報の受け渡し用として兼務しても良いのでしょうか？
それとも同じような内容だけど別のクラスを~Formとして作成することになるのでしょうか？

■Form,Model,Entity,DTOと似たようなモノが多く、使い所に困ります。一応、【〜違い】でググったりしました。
大きなモノを作流ときはメンテナンス性を考えてDTOとDAOで管理するような事が書いてありました。
■githubなどに掲載せれているソースコードにはEntityアノテーションを使ったものが少ないように感じます。
参考にしたプロジェクト
上記のリンクのプロジェクトなんかは~Formと名前をつけてSerializableを実装してentityとformを兼ねている？ように見えます。以下実装例Entityアノテーションはついていない。

@Setter
@Getter
public class LoginForm implements Serializable {

    private static final long serialVersionUID = 7593564324192730932L;

    @NotEmpty
    String loginId;

    @NotEmpty
    String password;

    // ログインしたままにするか
    boolean rememberMe;
}

Springのアーキテクト的に考えた場合と他の言語のFWを扱うときのことを考えると、敢えてアノテーションを使わずに作る方が後々他の言語を扱うときに入りやすいのかなと思ったり.....

話がまとまっておらず恐縮ですが、今回はとりあえずentityとして作成した（Entityアノテーションつきの）クラスをformとしてバリデーションなどの時の指定に使ってもいいのか。という質問内容でした。

Answer 1

Domaは JPAじゃないので @Entity がないだけでは？

入力エラー後に誤った値を保持する関係上、Formでは全て文字列(String)にすることが多いかと。

またパスワード・メールアドレスのように再入力（確認入力）のある項目もEntityをそのまま使った場合扱いづらいです。

Comments

[sanezane]

ありがとうございます。
確かにFormは全てStringでした。確認用パスワードをチェックするメソッドなどもFormを使うという事ですね。

Answer 2

これはいろいろな意見が出るところですが、Form(Bean)、Entity,DTOは分けた方が良いと思います。
StrutsやSpringの場合はMVCベースでとらえ、ViewとDB（テーブル）を分けて置いた方が後の変更に強いというメリットがあるからです。
（テーブル構造が変わったり、表示する内容が変わったときに、変更するコード量が減ったり、コードを変更する影響を局所的にとどめられる）

Comments

[sanezane]

ありがとうございます。
DTOはテーブルとのマッピング,Formはアプリ側の情報というわけ方をするのが普通という事ですね。