DAOでSQL指向のアプローチを改革する

入門

プロジェクトでは、データベースフレームワークを頻繁に処理する必要があります。 概念的に、これらのフレームワークは2つの大きなクラスに分けることができます。

• ORM指向
• SQL指向

それらのいくつかは良いですが、いくつかはあまり良くありません。 しかし主観的に言うと、SQL指向はORM指向に比べて開発が劣っています。 私は開発では強調しますが、機会では強調しません。 このスケールを変更することはできませんが、SQL指向のアプローチの世界に異常な外観を提供することはかなり可能です。 誰も気にしない、キャットへようこそ

ちょっとしたレビュー

違反する前に、私は非常に簡潔に何を思い出すことを提案します。 件名の誰がレビューをスキップしても構いません。

そのため、ステージでは、 ORM指向のアプローチの代表者は次のようになります。

• 休止状態
• Eclipselink
• ミバティス
• ジューク

これらの代表者はさまざまな方法で仕事をしています。 後者、たとえばDSL-wayは、データベーススキーマに従って生成されたオブジェクトまたは文字列のみを使用してSQLクエリを構築することを提案します。 その他は 、Javaオブジェクトとデータベーステーブル間の対応を記述する必要があります。 しかし、ポイントではありません。 それらはすべて、開発者をSQLクエリの作成から可能な限り隔離し、見返りにORMの思考を提供するという1つのアイデアによって結ばれています。

一方、SQL指向のアプローチの代表者が集まった：

• Spring Framework JDBC
• sql2o （本当に気に入った）
• Jdbi
• 改革

いずれかの形式のこれらのソリューションはすべて、 java.sql。*パッケージのアドオンです。 そして、これらのフレームワークが急になるほど、開発者は彼から隔離されます。 それでも、それらを使用する場合は、最初にSQLカテゴリを検討し、次にORMを検討する必要があります。

フレームワークの3番目のクラスであるジェネレーターの存在を知っています。 そのような決定は通常特定のプロジェクトのために書かれており、彼らが普遍的であることは難しいので、彼らがニッチを獲得することは困難です。 それらのアイデアは次のとおりです。特定のプロジェクトの知識、データベースの知識、およびビジネス要件の詳細を使用して、DAO層を完全に生成します。 私はそのような決定に二度会いました。 SQLクエリやマッピングを記述する代わりに、DAOレイヤーのジェネレーターを変更する必要がある場合は非常にまれです。

何が悪いの？

ORM vs SQL vs Generatorsという、このアプローチまたはそのアプローチに意図的に価値判断をしませんでした。 誰もが、状況と組み合わせて、何を選択するかを自分で決めます。 しかし、ここでは、SQL指向のスタイル表現と概念表現の両方で、特定の選択肢を提供する準備ができています。 しかし、最初に、既存のソリューションのコードレベル（パフォーマンス、デバッグなど-私はそれを省略します）で気に入らないと言います。

1. 単純なことを達成するための特定の冗長性
2. ボイラープレート、ボイラープレート、ボイラープレート...そして再びボイラープレート
3. sql-ormまたはorm-sqlオプションを表示できるコード内のポイントの不足
4. 何らかの形で、条件をフィルタリングしてSQLクエリを構築する
5. フレームワークAPIを使用するための多くの知識-コードを壊す前に+100500のエンティティについて学ぶ

上記の多くは、「あなたがそれを好きになるためにはどんな種類のフレームワークである必要がありますか？」

宣言的なスタイル

どっち？ 私はシンプルだと思うので、彼はコードを書き始めました。 しかし、真剣に？ 宣言的。 はい、私は命令的なものよりもそのようなことで宣言的なスタイルの支持者です。 宣言的アプローチに関して、Javaで最初に思い浮かぶのは何ですか？ はい、たった2つのこと： アノテーションとインターフェース 。 これらの2つの物質が交差し、SQL指向のソリューションのチャネルに向けられた場合、次のようになります。

 public interface IClientDao { @TargetQuery(query = "SELECT id, name, state " + " FROM clients " + " WHERE id = ?", type = QT_SELECT) Client findClient(long clientId); } 

これは単純な実例であり、その本質は、問題のフレームワークに反映されている宣言スタイルの概念を強調することです。 アイデア自体は確かに新しいものではなく、2006年頃のIBMの記事でこのようなことについてのメモを見ましたが、一部のフレームワークはすでにこのアイデアを使用しています。 しかし、そのような例を見て、私は合理的にいくつかの質問をするでしょう：

1. そして、IClientDaoコントラクトを実装するのは誰で、実装にアクセスする方法は？
2. そして、フィールドのマッピングはどこに記述されていますか？
3. もっと複雑なものはどうですか？ そして、これらの例はすでに3セントにうんざりしています。

私は、これらの質問とキャンペーンに答えて、フレームワークの機能を明らかにすることを提案します。

プロキシのみ

>> 1。 そして、この契約を誰が実装し、どのように実装にアクセスするのですか？

コントラクトはjava.lang.reflect.Proxyツールを使用してフレームワーク自体によって実装され、SQLの目的で自分で実装する必要はありません。 そして、実装へのアクセスは非常に簡単です。...の助けを借りて、はい、ところで、例で示すのは簡単です：

 IClientDao clientDao = com.reforms.orm.OrmDao.createDao(connection, IClientDao.class); Client client = clientDao.findClient(1L); 

接続は、たとえばjava.sql.Connectionまたはjavax.sql.DataSourceの実装、または一般的なオブジェクトなど、データベースにアクセスするためのオブジェクトです。 クライアントはORMオブジェクトであり、おそらくフレームワーク自体からの唯一のものはcom.reforms.ormクラスです。 OrmDaoは 、すべてのニーズの98％をカバーします。

コンセプト

>> 2。 そして、フィールドのマッピングはどこに記述されていますか？

上で約束したように、スタイルとコンセプトの2つのことに触れます。 2番目の質問に答えるには、コンセプトについて話す必要があります。 メッセージは、新しいものを提案するためには、解決策の根本的な見解が必要であるということです。 SQL-92パーサーはどうですか？ この考えが最初に思いついたとき、私はそれを投げて、二度と彼女に会うことはないと思った。 しかし、SQL指向のフレームワークを便利にする方法は？ 別のアドオンを見ましたか？ または、フレームワークのヘルパーに別のヘルパーをしますか？ 私の意見では、サポートされている一連のSQL構造を制限することをお勧めします。良い妥協案として、見返りに便利なものを手に入れることです。 マッピングは、SQLクエリを解析した後の式ツリーに基づいています。 上記の例では、列名はオブジェクトのORMフィールド名に1対1でマップされます。 もちろん、フレームワークはマッピングをサポートし、より複雑ですが、それについては少し後で説明します。

例

>> 3.もっと複雑なものはどうですか？ そして、これらの例はすでに3セントにうんざりしています。

しかし、フレームワークがより複雑なことを行う方法を知らない場合、SQL-92パーサーに煩わされる点はありますか？ しかし、 ボリュームのない例のすべてを表示するのは簡単なことではありません。 もちろん表示しますが、SQLのテーブル宣言とJavaコードの一部は省略します。

SQL指向のソリューションで私が一度も好まなかった数少ないことの1つは、SQLクエリを作成する必要があることです。 たとえば、特定のフィルタリング基準が指定されている場合と指定されていない場合があります。 そして、おそらくあなたはそのようなコードの断片、あるいはむしろその単純化されたバージョンに精通しているでしょう：

  // -  DAO private String makeRegTimeFilter(Date beginDate, Date endDate) { StringBuilder filter = new StringBuilder(); if (beginDate != null) { filter.append(" reg_time >= ?"); } if (endDate != null) { if (filter.length() != 0) { filter.append(" AND"); } filter.append(" reg_time < ?"); } return filter.length() == 0 ? null : filter.toString(); } 

そして、私はこの断片を、私が古いプロジェクトで最もよく会うように正確に書きました。 これは、PreparedStatementで値を設定するときに日付チェックが再び表示されるという事実にもかかわらずです。 そして、私たちの友人は何を提供していますか？ そして、彼は動的フィルターを提供しています。 例を使用すると理解しやすくなるため、一定の間隔で顧客を見つける方法を見てみましょう。

 public interface IClientDao { @TargetQuery(query = "SELECT id, name, state " + " FROM clients " + " WHERE regTime >= ::begin_date AND " + " regTime < ::end_date", type = QT_SELECT, orm = Client.class) List<Client> findClients(@TargetFilter("begin_date") Date beginDate, @TargetFilter("end_date") Date endDate); } 

そして最後の行は、たとえばbeginDateなどのパラメーター値がnullの場合、関連するSQLフィルターregTime> = :: begin_dateが最終的なSQLクエリから切り取られ、この場合、次の行がデータベースサーバーに移動することです。

 SELECT id, name, state FROM clients WHERE regTime < ? 

両方の値がnullの場合、WHEREセクションは最終クエリに含まれません。 そして注意-コードには宣言のみがあり、ロジックはありません。 私の意見では、本当に他の人の話を聞きたいと思いますが、これは強力な武器であり、フレームワークの強力な側面です。 Javaコードによると、私自身は注釈のファンではなく、ほとんどのプロジェクトの注釈の多くは単にうっとうしいと言うでしょう。 したがって、彼は定義した代替手段を提供しました-オブジェクトのbeanのプロパティでフィルタリングします：

 //  get/set  .   . public class ClientFilter { private Date beginDate; private Date endDate; } public interface IClientDao { @TargetQuery(query = "SELECT id, name, state " + " FROM clients " + " WHERE regTime >= ::begin_date AND " + " regTime < ::end_date", type = QT_SELECT, orm = Client.class) List<Client> findClients(@TargetFilter ClientFilter period); } 

かなり簡潔で理解しやすいことがわかりました。 動的フィルタについては、サポートする、または、OVERLAPSとMATCHを除くすべての述語から除外できるということを別に述べる価値があります。 「ライブ」SQLステートメントで後者を見たことはありませんが、SQL-92仕様で言及されています。

もちろん、フレームワークは静的な必須フィルターもサポートしています。 そして、それらはHQLやSpringTemplateの構文と同じです- '：named parameter' 。

確かに、1つの問題は常に静的フィルターに関連付けられています：「nullパラメーターへの応答方法」？ 簡単な答えは、「例外を投げてください、あなたは間違えられないでしょう」と言っているようです。 しかし、それは常に必要ですか？ たとえば、特定のステータスのクライアントをロードして、これを確認してみましょう。

 public interface IClientDao { @TargetQuery(query = "SELECT id, name, state " + " FROM clients " + " WHERE state = :state", type = QT_SELECT, orm = Client.class) List<Client> findClients(@TargetFilter("state") ClientState state); } 

しかし、データベース内のクライアントステータスが存在しない場合、タスクは何をすべきでしょうか？ 状態列ではNULL値が許可されるため、ステートレスのクライアントを正確に検索する必要がありますか？ SQL-92パーサーの概念が再び保存されます。 '：state'から'：state ？のステータスでフィルター式を置き換えるだけで十分です。 'フレームワークエンジンは、WHEREセクションを次の形式に変更します' ... WHERE state IS NULL ' 、もちろん、nullがメソッドの入力に含まれない限り。

マッピングについて

クエリのフィルターは確かに優れていますが、Javaソリューションでは、SQLクエリの結果をORMオブジェクトとそのバインディングおよびエンティティ自体のバインディングにマッピングすることに多くの注意が払われます。 非常に多くのJPA仕様がどれだけ価値があるかを見てください。 または、ResultSetからドメインオブジェクトへの移行、またはPreparedStatementでの値の設定でプロジェクトを確認します。 面倒ですよね？ 信頼性が低くエレガントではないかもしれませんが、間違いなくシンプルな道を選びました。 SQLクエリに直接マッピングを配置できるのに、なぜこれまでのところに行きますか。 これが最初に思い浮かぶことですか？

例を見てみましょう。 そして、ここに問題があります。テーブルのすべての列がORMクラスのフィールドと異なり、ORMにネストされたオブジェクトがある場合、クエリの結果をマップする方法は？

 public interface IClientDao { @TargetQuery(query = "SELECT cl.id AS client_id, " + // underscore_case -> camelCase  " cl.name AS clientName, " + //    camelCase " cl.state AS client_state, " + // any_type to enum   ,   enum   @TargetMethod " cl.regDate AS t#regTime, " + // t# -  ,        java.sql.Timestamp -> java.util.Date " addr.addressId AS address.addressId, " + //      ,   ? " addr.city AS address.refCity, " + " addr.street AS address.refStreet " + " FROM clients cl, addresses addr" + " WHERE id = :client_id", //        type = QT_SELECT) Client findClient(long clientId); } 

この例は、実際の条件により近いものです。 マッピングの美学は間違いなく不十分ですが、それでもこのオプションは無限の注釈やxmlファイルよりも私に近いです。 はい、信頼性に問題があります。ランタイムとORMオブジェクトのリファクタリングの問題があります。SQLを使用してお気に入りのデータベースクライアントでテストすることは常に可能とは限りません。 しかし、私はこれが絶望的な状況だとは言いません。テストはランタイムとリファクタリングを節約します。 データベースクライアントで要求を確認するには、「クリーン」にする必要があります。 別のポイント： どのSQLクエリがデータベースサーバーに送信されますか？ すべてのASセクションはリクエストからカットされます。 たとえば、client_idにcidの値をエイリアスとして保存する必要がある場合は、このエイリアスの前にコロンを追加する必要があります：cl.id AS cid： client_idおよびcidは有効です-> cl.id AS cid as final request。

そして最後に、少しのビジネスロジック

1つの操作が1つの宣言メソッドである場合の理想的なタオ。 そして、これは確かに良いことですが、これは常にそうではありません。 アプリケーションでは、データの一部が1つのSQLクエリによって形成され、他の部分が2番目のSQLクエリなどによって形成される場合、多くの場合、ハイブリッドまたは複合エンティティを取得する必要があります。 または、特定の接着、チェックを行います。 たぶんこれはタオ自体の本質ではないかもしれませんが、そのような操作は通常行われ、分離されますが、プログラムのさまざまな部分から呼び出すために公開されます。 しかし、ビジネスロジックをTaoに入れたい場合、インターフェイスで何をすべきでしょうか？ 私にとって、そして多くの開発者の意外なことに、java8にはデフォルトのメソッドが登場しました。 かっこいい はい、2017年がヤードにあるため、ニュースが悪いことを知っていますが、それでプレーできますか？ しかし、DAOレイヤーの開発の基礎として採用されている宣言型のスタイルと、ビジネスロジックの既定のメソッドを横断するとどうなるでしょうか。 オブジェクトのORMチェックをnullに追加し、別のDAOからデータをロードする必要がある場合はどうなるかを見てみましょう。

 public interface IClientDao { //     @TargetQuery(query = "SELECT id, name, state " + " FROM clients " + " WHERE id = ?", type = QT_SELECT) Client findClient(long clientId); //         IAddressDao getAddressDao(); //     default Client findClientAndCheck(long clientId, long addressId) throws Exception { Client client = findClient(clientId); if (client == null) { throw new Exception("  id '" + clientId + "'  "); } //       ,   IAddressDao addressDao = getAddressDao(); client.setAddress(addressDao.loadAddress(addressId)); return client; } } 

自分が正しいかどうかはわかりませんが、 インターフェイスプログラミングと呼びたいです。 そのようなもの。 実際、私が伝えたかったことすべて。 ただし、規定されたものを除き、フレームワークでできることはこれだけではありません：限られた数の列のサンプリング、スキームの管理、ページ付け（すべてではありません）、データの順序、レポート、更新、起動、削除の操作

おわりに

読者の皆さん、私はこの満たされたSQLフレームワークの世界に何か新しいものをもたらすことができたかどうかは知りません。判断するのはあなた次第です。 しかし、私は試しましたが、試したことに満足しています。 提案されたアプローチとアイデアがあればそれを批判的に見ることを楽しみにしています。 このソリューションはgithubで利用できます。リンクは、「SQL指向のフレームワークのリストの最後の行の概要」の章で既に示されています。 すべて最高。

エディトリアル

N1。 リストを返すメソッドの@TargetQueryアノテーションにオブジェクトタイプClient.classを追加しました。