JPAの実装を指定していた際に気になったことを解決するために作成したものをGitHubに公開しました。
https://github.com/pawn-4-git/AdvanceAbstractFacade_ver0.1
DBへの接続を実装する場合幾つかの方法があります。（NetBeansで実装する前提です）
１．JPQLによるアクセス
２．NativeQuaryによるアクセス
３．Criteria APIによるアクセス
また１はロジックの中で直接直接記述する場合とEntityのNamedQueryに記述する場合があります。
一番学習コストがないのは2です。これまでのSQLをそのまま適用できるので新しく覚えることはありません。ただし、ソースコード上に書くことになる場合が多いので記述ミスがあった場合、動作させて初めてミスが見つかる場合があります。また、変数の関連付けなどをすべて記述する必要もあります。
３の場合は記述ミスによる発生が発生しづらい記述方法です。ただし、完全にJavaのロジックになりますので、学習コストが大きいです。
そこで２を選択する場合があることが多いと思います。ただしNativeQueryと同様にロジックの中記述すると記述ミスによるエラーを実行してみるまでわからないということが発生します。
そこで、NamedQueryで実装することで学習コストが小さく、また記述ミスも少ない書くことができます。
NamedQueryはコンパイル時に記述する際に最もミスが起きやすい変数の部分をサポートで表示されるので記述ミスが少なくなります。
さて、NamedQuaryの問題は変数の値の埋め込みの部分になります。
例）SELECT c FROM hoge c WHERE c.delFlg = :delFlg
例の:delFlgの部分が変数になります。この部分に値の埋め込みをロジックで書く必要があります。当然検索や更新のたびにメソッドを増やすと使用するメソッドのミスなどで問題が発生する場合があります。
そこで直接NamedQuary名を指定してQueryを実行するためのクラスを作成しました。（GitHubに上げたものです）
変数はparameterパッケージにあるクラスに変数名と値を入れるか、ListBaseNamedParameterクラスのaddParameterメソッドに値を入れるとリストが作成されます。
あとはAbstractFacadeを継承したFacadeクラスを作成すれば、EntityのNamedQueryとListBaseNamedParameterを引数にメソッドに渡せば検索が可能です。
利点としては、DBのテーブルごとに作成されるFacadeクラスが肥大化することなく実装が可能になることと、NamedQueryが直接指定ができるので、メソッド名による実装のミスなどが減るかと思います。
かなり、荒っぽい実装なので参考にしていただき何かご意見がありましたらコメントをいただければと思います。
ちなみに、ロジックの中でJava8で導入された機能がありますのでお気をつけ下さい。