リッチなアプリ開発はデータバインディングが一つのキモがGood！ - おおたに6号機blog
どうも。夏休みボケなDQNです。 id:kagamihogeさんの「リッチなアプリ開発はデータバインディングが一つのキモ」が 非常によいエントリです。 とりあえず重要なのは、Web ベースの業務アプリの流行の一つに、 再びクライアント側重視の流れがあるらしいこと。Web アプリは、サーバサイドで 色々ゴチャゴチャ処理したあと最後にヴァーンと html を吐き出して終わり、というシンプルなのが 基本形である。しかし、Ajax, Flex, Silverlight などなど―どんな技術を採用するのかの 違いはあるが―こうしたリッチな技術を使う場合、データ表現は html、サーバ側で何がしか処理、 とシンプルな分離だけでは収まらなくなる。 http://d.hatena.ne.jp/kagamihoge/20080925/1222337488 この辺に激しく同意ですね。言い方を変えれば、クライア
リッチなアプリ開発はデータバインディングが一つのキモ - kagamihogeの日記
リッチインターネットアプリケーション（RIA）の開発では、ある技術がデータバインディングをサポートしているかどうかとそのやりやすさが、一つのポイントになる、と感じている。 俺がデータバインディングという概念を初めて意識するようになったのは、Flex 3 が最初。その後、Silverlight や WPF ではどうなのかをわんくま勉強会で聞いたり、Seasar Conference では Uruma や S2Swing でもちょこっとデータバインディングについて話していたのを聞いた。それらを聞いて今感じていることがある。データバインディング機能の優劣だけでは、ある RIA テクノロジーがこの先生きのこるかどうかを決定付けるほどの重要さは無い。ただし、データバインディングがやりやすいかどうかはリッチなアプリの開発がやりやすいかどうかにジワジワと利いてくる。このため、データバインディングは「地味
今だから出来る業務システムを
先日、とある業務システムの事例が発表されていました。最先端を好むエンジニアに評判の良い最新技術を採用しての開発ということで大きく注目を集めたようです。その事例記事自体は普通の紹介記事なので、そこからあれこれと邪推するのもどうかと思うのですがいくつか気になるところがあり、それが日本の業務システムの問題の一部を体現している気がするので、ちょっと気になるところを書き連ねてみます。 その記事には画面のスクリーンショットが掲載されていました。見た瞬間に「未だに？」と感じてしまいました。どういうことかというと、画面の一番上がラジオボタンになっており、 ◎追加 ○更新 ○削除 と、まずは今から行う操作の種別を入力するようになっているのです。 これは「伝票入力する」という業務がそのまま残っているということになります。どういうことかというと、昔々というのはコンピュータが非常に高価な時代でした。そこでまずは入
［要件定義/システム設計編］設計/アーキテクチャの不備
最後に，設計/アーキテクチャの不具合で火を噴いたプロジェクトの火消し術を取り上げよう。この場合の主な対処法は，（1）原因を特定して技術的な対策を打つ，（2）設計書をレビューする，（3）運用でカバーする，の三つである。 システム開発プロジェクトのコンサルティングを手がけるフィッシュボーン研究所の大坪保行氏（代表取締役社長）は，テスト・フェーズで当初見込んでいた処理性能が出ないことが露見したEDIシステムの開発プロジェクトを支援したことがある。 そのシステムは，あるWebアプリケーション・サーバーを使って開発していたが，システムの総合テスト・フェーズで，トランザクション処理性能が全く出なかった。詳しく調べてみると，システムが受け付けたすべての処理を，Webアプリケーション・サーバーが待ち行列（キュー）で管理していることが分かった。 本来ならWebアプリケーション・サーバーの特性をつかんで，キュ
第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法
システム化業務説明書とは，ある「システム化業務」の中で「利用者がシステムに対して行うこと」「システムが利用者に対して行うこと」「システムが内部的に実行する処理」を，「シナリオ形式」で記述した仕様書のことです。 システム化業務説明書を作成することで，利用者がシステムをどのように利用するのか，システムがどのような振舞いをするのかが明確になるため，発注者と開発者間でシステムの振舞いについて共通認識を持ちやすくなります。 逆にシステム化業務説明書を作成しないと，システムの振舞いについての認識がずれてしまい，その結果，発注者の期待した動作をしないシステムが構築されてしまったり，業務上意味のない機能を作成してしまい無駄なコストがかかってしまう，といった危険性があります。発注者と開発者間の認識を合わせるという意味で，この工程成果物は必須と言えるでしょう。 3つのシナリオを考える 図2に，システム化業務説
クラス設計の常識に反して、クラス名を動詞に、メソッド名を名詞にする - kなんとかの日記
クラスを作るとき、ふつうはクラス名を名詞に、メソッド名を動詞にする。 class FileLoader { // クラス名は名詞 def load(name) { // メソッド名は動詞 ... } } しかし PHP のフレームワーク CodeIgniter では、一部のクラスでこれが逆になっている。つまり、クラス名が動詞で、メソッド名が名詞なのだ。 class Load { function model($name) { ... } function helper($name) { ... } function library($name) { ... } } CodeIgniter では、このクラスのインスタンスが、クラス名と同じ名前で $this に設定される。そのため、実際使うときはこんな感じ。 $this->load->model('User'); // モデルをロード $th
ドメイン層に最適なアーキテクチャを考える
サービス層が持つべき機能とは 次にドメイン層について考えて見ます。サービス層は、業務サービスを実現する層です。サービス層はドメイン層に存在するビジネスロジックを利用してサービスを実現するためのサービスプロセスを実現しています。 そして、トランザクションの制御、セキュリティなどのシステム機能を実現します。 このとき業務機能（機能要件）とシステム機能（非機能要件）を実現する実装は、分離できるようにします。一般的にはEJBやAOPなどのフレームワークを利用し、ビジネスロジックにシステム機能が混在しないようにします。 ドメイン層の設計をどのように考えるか ドメイン層は、ビジネスロジックを実装します。ビジネスロジックは、必要とするデータとともにエンティティクラスにカプセル化されます。これは、オブジェクト指向分析で作成された概念モデルを基に作成します。各エンティティクラスは、継承、インターフェイス、関
Transaction Script(Domain Logic Patterns)
Domain Logic Patternsは、ドメインロジック－よくビジネスロジックとか言われているもの－をどのように構成・配置するかについてのパターン。 概要 プレゼンテーション層からのリクエストを、ひとつのProcedureとしてまとめる形でドメインロジックを構成するパターン。メリット シンプルさ！-> 理解しやすい。 -> メンテナンスしやすい。 他のトランザクション（nearly equal ドメインロジック）のことを気にしなくていい。-> 多人数の並列開発に向いている。 -> スキルが低い開発者による低品質なコードの影響を局所化できる。 デメリット 同じようなコードがあちこちに出てきやすい。結果的に、規模が大きくなりやすい。注意 1メソッド・1クラスとして構成する必要があるわけではなく、必要に応じて構造化する（当たり前）。間違っても常に1メソッドとして作ったりしないこと。レイヤ構
PofEAA's Wiki - (ファウラー | 読書会)
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
混ざると管理しにくいすごいコード - きしだのHatena
すごいコードとそうではないコードが混じると管理しにくいということですが、実際そうですよね。 すごくセンスのある人がいて、ビックリするようなテクニックを使って追いにくいコードを書く人がいます。 すごいな〜とは思うけど、できればやめて欲しいですね。 よくあるのが、みんな使ってないけどその人だけが使ってるライブラリ。それもプログラムの作り方に影響しそうな。 例えば、その人のコードだけBeanUtilを使って、そのためにBeanがちゃんと書いてあったり、それぽいところはないのに1行でデータコピーしてたり。BeanUtilだと何かの依存ライブラリとして使える状態になってたりするし。 でも、これは局所的です。それに、わかってしまえば追うのはたいしたことない。使えるものは使うというのも、まあ悪くないと思います。 たちが悪いのは、オブジェクト指向だったり30行メソッドとかメンテナンスしやすさテストしやすさ
第1回 階層化アプリケーションとは | gihyo.jp
小規模～大規模のシステム構築を検討するにあたり、システムを階層化して構築することが多くなっています。人は、複雑なものをまとめて理解することはできません。そこで、階層化しそれぞれの階層に意味づけを行うことにより対象物を理解しようというわけです。そこで本連載では、今さらかもしれませんが、n階層アーキテクチャアプリケーションについて説明したいと思います。 n階層アーキテクチャアプリケーションのメリット・デメリット n階層化アーキテクチャとは、アプリケーションを表示、業務処理、データ等、複数の階層で分割する分散アプリケーション設計手法のことを指します。 階層化にはどのような視点で分割するかによって、大きく「論理的役割」による分割と「物理的役割」による分割に分類できます。 論理的役割による分割とは、画面表示部、業務ロジック部、DB、ファイルなどのデータ格納部といった各階層の役割を意識して分割される場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
