blogこの広告は、90日以上更新していないブログに表示しています。使わないデータアクセス最近は、データベースをアクセスする時は以下のようにしています。そのまま使う事が多かったのですが、上のようにスタイルを変えた結果、今の所結構うまく行っているので、紹介してみようと思います。よらない物だと思っています。出た辺りから、一部の言語では例外はあるものの、全体としては後者が主流なように思います。構築していくような物が最近はメジャーになってきています。以下のように書いて問い合わせを実行します。c)));各オブジェクトは以下のようになります。SQLのクエリを構築する為のビルダーです。等のメソッドを用意しています。メソッド等で問い合わせを実行して、結果を返します。テーブルを表すオブジェクトです。これらのクラスは自動生成されます。各テーブルの属性を表すオブジェクトです。サポートはまだ開発中らしく、ラムダのサポート等はありません。こちらで独自で作成しています。文を構築するような事はせず、中間層を設けています。具体的には、以下のように問い合わせを行う為の「クエリ」クラスを通しています。クラスのインスタンスをラップし、以下の機能を提供しています。依存するような問い合わせメソッドを用意していません。形式毎にメソッドを用意する、といった事は必要ありません。どの属性が必要とされるかがクエリオブジェクト側に渡されるので、取得する属性に応じて最適化をしやすくしています。更新用オブジェクトを別途用意する更新をする場合は、全く別のクラスを用意しています。...}更新処理用のクラスは以下のように分割しています。レコードの登録/削除の機能を提供。レコード/エンティティに近いが、参照系の機能は提供しない。以下のような利点があると思っています。呼び出しを遅延実行したり、必要の無い属性を取得したりする事があると思います。便利ではあるのですが、開発者としては挙動が予想しにくく、複雑な問い合わせ処理をしようとすると結構はまってしまいます。よって異なり、きちんと理解するにはドキュメントを読む必要があります...が、そこまで勤勉な開発者は正直な所少ないのではないかと思います。そもそもドキュメントがなかったり実際の挙動と異なる事もあります。そのものなので、書かれた通りに実行されます。意図しない動作がされる事は非常に少ないと思います。(7以下)の表現力の問題なのですが、関数リテラルが使えない為にデータの加工がどうしても面倒になります。追加」といった流れのコードが増えます。任意のオブジェクトに変換する為の(関数?)オブジェクトを生成し、渡すことになります。これらのオブジェクトは自分で作る事も出来ますし、「コンストラクタ呼び出し」等の一部の処理は用意されています。違って、属性が変数として渡せるので、再利用性が高くなっています。);上記に加え、以下のような傾向があるように思います。明確な特徴とは言い辛いのですが、どちらかと言うと、こちらの方が効果が現れるとうれしいです。変換処理を使い回すコードが増える傾向があるように思います。変換処理を使い回すようになると、以下のような弊害が出てくるように思います。使用ケースに対して最小公倍数的に属性を持つことになる。その結果、無駄な属性が増えてDTOがふくれあがってくる。下手すると、本当は使用していない属性を至る所で渡すことになる。修正に対する影響箇所が増え、修正が難しくなる。修正することになり、結果クラスがふくれあがってくる。数やそれに対する依存性が減る事が期待できます。レコードクラスに対してメソッドを追加することができます。レコードクラスにメソッドを追加して「リッチな」モデルを構築する、というアイデアは非常に直感的ではありますが、いざレコードクラスにロジックを書いてみると意外とコードが長く、締まりのない物になったりします。一因として、更新系のコードと参照系のコードは共有できるコードが薄い事あると思っています。具体的には、参照系と更新系の処理は以下のような物になるでしょう。参照系は変換ロジックが複雑になる傾向にあり、一方で更新系は様々な外部サービスに依存する傾向があります。結果として、全く違うコードになり、共有が難しくなります。今回の方法では更新と参照は全く別のクラスとして扱う事で、クラス内のコードの凝集性が向上します。速くなる必要な属性だけを取得するので、無駄な問い合わせ処理を行わなくなります。そのため、問い合わせが速くなる傾向にあると思います。等が減ったりする事があります(した)。逆に欠点を考えると、以下のものがあるように思います。用意した恩恵が得られない。テーブルからクラスを生成しているので、そのための設定がいる。ビルドツールによっては難しくなる。素朴なツールを使うため、最初の作り込みのコストがかかると思います。使った方が良いように思います。等)の上に構築する事もできるようです。ベースに上のようなクエリ/リポジトリ/エンティティを作る事も出来ると思います。あと、これは欠点というわけではありませんが、動的な型付け言語では、若干メリットは薄いかもしれません。等)が強力なので十分な場合が比較的多いと思います。問い合わせ処理の見通し易さの向上や、コードの凝集性の向上等は動的言語でも同様に得られるのではないかと思います。使う以外の方法として、最近実践している方法を書いてみました。呼ばれる方法を拝借して簡易的にした物です。自体は「コマンドクエリ分離」の考えを拡張し、操作と参照をクラスで分離するという意味以上の物はないようです。呼ばれるアーキテクチャの話とセットで語られる事が多く、こちらを含めるとコーディング方法がかなり変わってきてしまうため、採用はしていません。〜iOS編〜に参加した月別アーカイブはてなブログをはじめよう!wm3さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。