私はEMFプロジェクトに取り組んでいます。設計上の決定の1つは、生成されたコードに触れたりチェックインしたりしないことでした。代わりに、何かを変更する必要があるときはいつでも、変更を含むサブクラスが作成されます。フレームワークはこれに対処するのに十分な柔軟性があります。ただし、作業のオーバーヘッドが発生します。
設計上の決定は、他のコード生成フレームワークでの悪い経験に基づいて行われ、問題が発生した場合に再生成されました。
プロジェクトに不慣れなので、その設計上の決定に挑戦したいと思いますが、最初に一般的な意見を聞きたいと思います。EMFプロジェクトチームがコード内の変更を推奨していることを私は知っています。しかし、あなたの経験は何ですか？EMFは、生成されたコードの手動コード変更をどの程度適切に処理しますか？手動で記述されたコードを失うことになったことがありますか？コードが保守不可能な状態になったことがありますか？
しかし、あなたの経験は何ですか？
私は 2 つの別々のプロジェクトを実装しました。どちらも 50 以上のモデル クラスを持つモデルを含み、どちらの場合も、モデルはプロジェクトの存続期間を通じて進化しました。つまり、多くのモデルチェンジです。どちらの場合も、生成されたコードを変更して、通常は計算された属性と検証を実装し、さまざまな方法でエディターをカスタマイズしました。
EMF は、生成されたコードの手動コード変更をどの程度うまく処理しますか?
それはうまくいきます。ジェネレーターは、モデルの変更によりコンパイルできないコードを生成することがありますが、通常、修正は簡単です。たとえば、Java クラス/インターフェースの削除、無効なインポートなど。
手動で書かれたコードを失うところまで来ましたか?
ごくたまにしか。ときどき、「生成された」マーカー コメントを削除するのを忘れて、モデルを再生成するときにメソッドが壊れてしまいます。
(それが大きな懸念事項である場合は、EMF ジェネレーターを変更して、変更をマージする前に常にソース ツリーをバックアップできると思います。)
一番いらいらしたのは、生成されたコードをフォーマットしなければならなかったことだと思います。残念ながら、Eclipse のコード フォーマッタは非常に粗雑ですが、手動で再フォーマットすると、次に再生成したときにフォーマットの変更が失われます。しかし、それはただイライラするだけです...回避するためにフープを飛び越える価値のあるものではありません.
コードが保守不可能な状態になったことはありますか?
いいえ。決して。
consta_a の回答を読むと、生成された EMF クラスを常にバージョン管理にチェックインしていたことを思い出します。これは、長期的に手作業による編集が失われないようにする最善の方法です。
2018 年の更新: 私が話していた 2 つの EMF プロジェクトは 2008 年以前に発生しました。それ以降、EMF の世界では状況が変わっている可能性があります。私は追跡していません。
Stephen C の回答を確認します。私たちの場合、モデルで約 120 のクラスを処理します。つまり、120 のインターフェイス + 120 の実装クラス + 無数の編集クラスを意味し、再生成は非常にうまくいきます (必要に応じて生成されたクラスを簡単にフォーマットできれば ( ^_^))
ヒント: 手作りのコードを失うことを恐れている場合は、コードをリポジトリに保管することをお勧めします。変更を行うたびに、以前のバージョンと簡単に比較して、変更点を確認できます。