ひがやすを blog：「レイヤモデルアーキテクチャ」
レイヤアーキテクチャの場合、ある層は、自分の直接下位の層にのみ依存し、それ以外の層には依存しないのが基本です。通信は、下位の層とデータをやり取りすることで行います。 それでは、このデータはどの層に属するのでしょうか。層に属することにすると、層間で通信するごとにデータをそれぞれの層のデータに変換する必要がでてきます。 例えば、A -> B -> Cという層間の呼び出しの場合、A層のオブジェクトはB層のデータに値を詰めてB層のオブジェクトを呼び出し、B層のオブジェクトは、B層のデータをC層のデータに変換して、C層のオブジェクトを呼び出します。戻り値の処理はこの逆です。B層のオブジェクトは、C層のオブジェクトの戻り値(C層のデータ)をB層のデータに変換して、戻り値として返します。かなり大変です。層が増えれば増えるほどこのオーバーヘッドは大きくなります。 そこで、データ部分は、どの層にも実装上依存
3つのモデル - どのモデルを中心にするのか（ひがblog）
id:n-ichimuraさん、S2Laszloの開発は止まっているようですが、別の方に引き継いでも良いですか。よろしくお願いします。 http://d.hatena.ne.jp/higayasuo/20050825#1124957707で書いたActionとServiceの統合ですが、いろいろ考えてみましたがActionの責務が多いと思うので、やはりActionとServiceは分離すべきだと思います。 そもそもこの話は、Dxoをどこに置くべきかの話だったのですが、やはりServiceにおくべきだと思います。 モデルは、その使われる場所によって、プレゼンテーションモデル、ドメインモデル、ERモデル(RDBMSの場合)に分かれます。プレゼンテーションモデルはプレゼンテーション層で使われ、ドメインモデルはビジネスロジック層で使われ、ERモデルはリソース層で主に使われることになります。 どのモ
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
