サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Appleイベント
blog.fukuchiharuki.me
※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある3層構造です。何を見直して再設計するのか?それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く?本当に? 開発対象のシステムはある情報の検索
リポジトリとDAOは似ています。どちらもデータストアとアプリケーションコードの間に位置します。 しかしリポジトリとDAOにはやはりどこか違いがありそうです。リポジトリとDAOの違いはどこにあるのか、参考文献からそれぞれの目的を調べてみます。また具体的にリポジトリとDAOをどう使い分けられそうかを考えてみます。 リポジトリはドメインオブジェクトのコレクション A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. – P of EAA: Repository リポジトリはエンタープライズアプリケーションアーキテクチャパターンにおいて次のように説明されています。リポジトリはドメインとデータマッピングレイヤをとりなして、
Last modified at: March 28, 2017 リポジトリとDAO、どちらもデータベースなどのデータソースにアクセスするための設計パターンです。しかし、データベースにアクセスする、では括りが大き過ぎますね。 今回はリポジトリとDAOの違いについて書きます。クラスの役割を明確にした設計ができるように、違いをきちんと考えてみたいと思います。 仕組みを意識せずにデータアクセスできる、それがDAO separates a data resource’s client interface from its data access mechanisms – Design Patterns: Data Access Object データリソースを扱う窓口をデータアクセスのメカニズムから分離するのがDAOです。SQLなどを使ったデータアクセスを業務ロジックから切り離そうということですね
このページを最初にブックマークしてみませんか?
『ふくちはるきのブログ – 30代×フリーランス×ソフトウェアエンジニアのブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く