0
Freemarkerを使用して、データモデルに基づいて出力を生成し始めました。私が直面している問題は、出力生成のためにデータモデルにメソッドを公開し続けていることです。だから私は私のFreemarkerテンプレートの唯一の目的のために私のデータモデルを "汚染"する気持ちがあります。Freemarkerデータモデルの汚染
次に例を示します。私の場合はインターフェースである
私のデータモデルは、この方法（図の名前とタイプを変更）を提供：テンプレートを書き込むために
Collection<MyPojo> getMyPojos();
を方法私はそれを想像して、私はいくつかの条件に基づいてMyPojoのいくつかをフィルタリングする必要があります。私はまずテンプレート自体でそれをやりたかったのですが、テンプレート内のリストを操作するのは非常に複雑でした。
は、だから私はニーズをカバーするために私のインターフェイスに他のメソッドを追加することになった：
Collection<MyPojo> getAddedMyPojos();
Collection<MyPojo> getRemovedMyPojos();
Freemarkerのドキュメントを読んで、私はテンプレートエンジンに多くの方法を提供するために、いくつかのFremarker APIを使用する方法を発見しませんでした。
この目標を達成するためにFreemarkerの方がスマートな方法はありますか？私はインターフェイスを最初のメソッドだけできれいにしておきたいと思います。最初のデータモデルを拡張する専用のデータモデルを作成する必要がありますか？または、マップを作成し、私のデータモデルの代わりにこのマップを挿入する（そして、私のメソッドの結果をそれに挿入する）？
ありがとうございます！
FreeMarkerにはビューモデルが必要です。ビューが単純化されている場合は、データモデルを直接使用するだけで十分ですが、それでも多くの人があなたがしてはならないと主張します。並べ替え、フィルタリング、計算などの作業を行う場合、ビューには専用のモデルが必要です。つまり、ストレージとビューの懸念を分ける必要があります。 –
ありがとうグレンあなたのコメント。あなたの意見では、インターフェイスを提供するのではなく、必要に応じてより多くのメソッドを公開できる実装を提供するべきですか？ – Xendar
あなたのFreeMarkerテンプレートによって排他的に使用される専用POJOを作成します。データ・インタフェース*またはその実装は、ビューに関わるいかなる懸念や礼儀もありません。私はそれが非常にOOPのようには聞こえませんが、データとビューは非常に別々の懸念事項です。あなたは "POJOを見る"ことができますが、データインターフェイスをコンストラクタの引数として取ることができますが、データ*実装*を認識させることはありません。 –