VO, DTO, POSO, DAO, Entity の違い - Qiita
はじめに try! Swift ではじめてDTO、POSOという言葉を聞いて、Entityとの違いとかよくわからなかったので調べてみた。 すると、類似の用語が5つでてきた。 VO (Value Object) DTO (Data Transfer Object) POSO (Plain Old Swift Object) JavaだとPOJO (Plain Old Java Object) DAO (Data Access Object) Entity いずれもシンプルに関連するデータをまとめたobjectだが、微妙に性質が異なる。 VO (Value Object) getterのみ 不変 DTO (Data Transfer Object) VO + setter 可変。外から変更可能 異なるレイヤー間（モデル層、ビュー層など）でデータを受け渡すのに使う POSO (Plain Old
お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさんは、Modelと言われたときに何をイメージしますか？ こんなアレを思い浮かべた方も多いかと思います。 マサカらせてください。やはりお前らのModelは間違っている。 アレをModelと呼ぶと何が不味いのか すみません、早速言い過ぎました。半分は正しいです。MVCの発明者、Trygve Reenskaug氏による1979年の説明によると、 Models represent knowledge. A model could be a single object (rather uninteresting), or it could
Webアプリケーションの構成に関する予備知識 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分の担当したWebアプリケーションを引き継ぐ際に、予備知識として説明したことのまとめ 注意事項 もともと明確に定義されていない概念や、簡単に説明するため正確さを犠牲にした部分が多い 間違っていることを前提に、疑いながら読むのがベター アプリケーションの層構造 アプリケーションを構成するオブジェクトには非常の多くの種類がある アプリケーションの（より良い）構成をオブジェクト単位で考えるのは難しいので、もっと粒度の大きい単位で考えたい アプリケーションをいくつかの層（オブジェクトの所属するグループ）に分割し、層単位でアプリケーションの構成
Post by @dekasasaki · 3 images
JPOUGのAdvent Calendar 12/15 担当です。 先日開催された db tech showcase 東京 2014 で関口さんが聴講者向けに「この中にモデリングを実際にやったことがある人はいますか？」という質問をしましたが、なんとほとんど手が上がらなかったのですね。「みんな意外とモデリングしてない？」そう思って本日の記事を書いてみることにしました。 先に私のことを書いておきましょう。私はDBエンジニアではありません。金融系が主なフィールドで、どちらかというとプラットフォーム(IT基盤)やアプリケーション(AP基盤)を得意とする分野で働いています。ですので、E-Rデザインに特化したお話ではありません。オブジェクト指向をベースにモデリングの本当に最初の最初にあたるステップのお話をします。 抽象度が高いレベルですから、モデリングをやるにはER図でもいいだろうし、私個人はUMLの
EC機能のドメインモデル設計（簡易版） - Qiita
ドメイン駆動設計（Domain Driven Design） ドメインとは 商品を検索する 商品をカートに入れる 商品を購入する など、アプリケーションを通じてユーザーが実際に取る行動、もしくは行動したいという要求（関心事） ドメインモデル エンティティ 値オブジェクト サービス ドメインモデルのライフサイクル管理 アグリゲート ファクトリー リポジトリー エンティティ 一意となる要素を保持するオブジェクト ユーザー カート 商品 など 値オブジェクト 保持した値が決して変更されない不変のオブジェクト 都道府県情報 郵便番号情報 決済代行サービス など サービス エンティティでも値オブジェクトでもない処理を持つオブジェクト 検索処理 など ファクトリー オブジェクトの生成をカプセル化 リポジトリー 永続化されたオブジェクトへのアクセス手段を提供 アグリゲート エンティティ間の依存関係を保持
Rails で fat model を避けるための、あまり知られていない方法について - おもしろwebサービス開発日記
このエントリで書いた内容は、ほぼ Growing Rails Applications in Practice の内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。 はじめに Rails で fat model を避けるための方法は、7 Patterns to Refactor Fat ActiveRecord Models を始めとして、多くのやり方が存在します*1。 validation や callback は ActiveRecord(以下AR) を継承せずとも利用することができます。7 Patterns to Refactor Fat ActiveRecord Models の 「3. Extract Form Objects
CakePHP3のORMを使う際に欠かせない概念について - Qiita
諸事情あって、バタバタしているyandoです。 18時過ぎに自分の番である事に気がついてしまいましたが、この記事はCakePHP アドベントカレンダーの9日目です。 CakePHP3で一新されたORMは「結果が配列からオブジェクトになった」というだけではない違いがあります。 それが Eager loading と Lazy loading です。この概念を理解していないとORMの機能を間違って使ってしまうかもしれません。 何が起きるの? N+1問題 ORMからクエリを実行した時にJOINを使ったクエリを実行するか、シンプルなクエリを実行するかのルールが分かりますか？ 従来のCakePHPではJOINの条件などに応じて自動的に決定されており、関連データを取得するためのクエリが大量に実行される場合がありました。たとえば画面に表示している20件のデータを取得するクエリを実行し、その後に20件のデ
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！ - Qiita
ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。(詳しくはエンタープライズアプリケーションアーキテクチャパターンという書籍を読むと良いです) この方法はロジックが複雑でない場合、つま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Deprecate TableRegistry static API. by robertpustulka · Pull Request #10933 · cakephp/cakephp