業務アプリには関数と構造体だけあればいい件について - yojikのlog
たけぞうさんやひがさんの古いエントリをよんでいまさら考えてみました。 http://www3.vis.ne.jp/~asaki/p_diary/diary.cgi?Date=20070128#2007012800 http://d.hatena.ne.jp/higayasuo/20070129#1170052662 関数と構造体しか無い、いわゆる構造化設計*1だと、上位の関数が下位の関数に処理を委譲して・・・みたいな感じで、機能のツリー構造が出来上がる。このような構造では必然的に、上位レベルの関数が下位レベルの関数(のインタフェース)に依存することになると思う。上位の関数が、下位の関数の面倒見る*2から。(追記: 厳密には関数を持つモジュールのツリー構造が出来あがる) ならば下位の関数のインタフェースをカッチリ決めれ! といわれそうですが、なんだかんだで下位の関数こそ変更されやすいのが業務
2007-01-29
デブサミ-VisualBasic, Delphiから10分でJava+Flex2にポーティング http://d.hatena.ne.jp/higayasuo/20070118#1169099987 Flex2では、モデルとUIコンポーネントと間の自動バインディングがサポートされています。自動バインディングとは､モデルの値が更新されたら自動的にUIコンポーネントの表示が更新されたり､UIコンポーネントに入力している値が変わったら､自動的にモデルの値を更新する機能です。 デフォルトではバインディングは単方向です。基本的には､モデルの変更をUIコンポーネントが検知するだけ。例えば､次のようなMXMLがあったとします。 <?xml version="1.0" encoding="utf-8"?> <![CDATA[ [Bindable] private var hoge:String; ]]>
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
