.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
MVVMパターンに関する認識・知見があちこちに散らばっているように見えるので、そろそろまとめてみる事にしました。この記事は、他の各サイトの記事などでMVVMの基本的な考え方・実装方法などを把握されている方が対象です。 そういった方がMVVMパターンを実務に適応してみようと思った時や、MVVMパターンを要件に合わせてカスタマイズしていく際に、認識すべきパターンの実装方式のそもそもの理由と考え方、要件に合わせて考えていかなければならないポイントを把握する助けとなる情報を提供するのを目的としてこの記事を書きました。(文字ばかりですいません＞＜) MVVMの実装の各要素の実装をこねくりまわすばかりで、その過程でパターンを把握している気になって、パターンの本来の目的を破壊してしまうような実装を推奨してしまっている人も見ます。そんな滑稽な事をしない認識を持って欲しいのです。 MVVMパターンは、WPF
WPF/Silverlight開発において、イベント駆動開発じゃ何故いけないのか？ MVC/MVP/PMパターンとMVVMはどう違うのか、どういったメリットがあるのか？ そういう声を聴く機会は少なくありません。 MVVMパターンとイベント駆動開発、MVC/MVP/PMパターンとの関係について僕の理解をまとめました。 MVVMパターンをわざわざ適応する事に疑問がある方にはぜひ読んで欲しいと思っています。 また、このドキュメントを記述するにあたり@matarilloさん、@ufcppさん、@yfakariyaさん、諸先輩方３方に叩き台を見ていただき多くの指摘を頂くことができました。今回は頂いたフィードバックを受けて公開する形になっております。 押しつけがましくも一方的に依頼させていただいて、にも拘わらず非常に丁寧に様々な指摘・示唆を頂くことができました。 この場を借りてお礼申し上げます。ありが
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
詳細設計書は書きたくない。 理由はだいたい つまらない 誰もみない 実装するより時間がかかる 実装するより記述量が多い 結局、自分で実装する ってところ。今まで書いてきた（書かされた）詳細設計書といわれるものはだいたいこの条件を複数満たしている。それでも納品することが求められる（たぶん習慣的に納品することになっているという理由だけ）ため書かないといけない。 今のプロジェクトも今のところ自分で実装する以外すべてを満たしている。記述レベルはプログラムとほぼ同等で１メソッド毎に使用するクラス名、メソッド名、定数名、変数名、ループ、条件分岐を処理順に書くことになっている。１処理（メソッド実行、分岐など）ごとにシーケンス番号をふり、階層ごとに子の番号を追加する。 設計書（詳細設計書、プログラム仕様書中心）に関するネット上の記事をちょっとピックアップしてみた。詳細設計書が必要だという人と不要だという人
マイクロソフトのDevLabsで公開されている.NETにおける設計とテストにおけるテクノロジーであるCode ContractsとPexを使ってみました。 結論から言うとかなり使えそうでひょっとしたら開発スタイルを変え可能性があると思いました。 かなり奥が深そうでまだ可能性と限界について完全に理解できているわけではないのですがまだ日本語で紹介している情報が少ないようなので書きたいと思います。 Code Contractsは.NETで「契約による設計（DbC:Design By Contract）」を実現するためのランタイムとVisual Studioに統合される開発環境です。 つまりC#などの言語で契約、つまりメソッド毎に「事前条件 (precondition)」「事後条件 (postcondition)」とクラス（インスタンス）における「不変条件 (invariant)」を記述することで
文字数の関係で記事を２つに分割します。（前の記事から・・・） ■マスタ情報を複写して管理（パターン５）取引が発生した時点の商品情報を取引（トランザクション）に複写して持つことにより、過去の商品情報を管理するようにします。【図５】 ①参照時点のマスタ情報をトランザクション側に持つ場合、マスタ情報の変更が発生した場合、トランザクション側の情報も同期をとって変更する必要があります。② . . . 本文を読む
ＯＯエンジニアの輪！ 第 42 回 黒枝 真(makotan) さんの巻 今回のゲストは、makotan さんです。ワークステートエンジン Buri の開発などをはじめ Java のオープンソースプロジェクトの開発で知られています ■ 始めに --- 前回インタビュイーの arton さんから makotan さんをご紹介いただきました。arton さんとはどのようなつながりですか？ あの、宴会です。(笑) 20世紀ギリギリくらいの頃ですね。Seasar ( の開発 ) が始まる前後に飲み会があって、そのときに arton さんに初めて会いました。この人が arton さんなんだ、あの Ruby 邪道編を書いた人なんだ、というところから入りつつも、技術の話は一切してなかったですね。 --- じゃあ、Seasar 本関連とか Seasar プロジェクト関連とかとはちょっと違う。プライベート的
エクスプレス開発バイブル（7）： エクスプレス開発は、クラウド時代に本領を発揮する いかにして開発を効率化し、納期を短縮化するか？ 家造りの考え方を参考に短納期開発の方法をあらゆる確度から紹介してきたエクスプレス開発バイブル。最終回となる今回は、従来以上にスピードが求められる本格的なクラウド時代の到来に備え、いま一度、エクスプレス開発手法の実践のポイントを振り返っておこう。（2010/9/16） エクスプレス開発バイブル（6）： 2チーム制で、開発効率とユーザー満足度を高めよう！ 開発する機能の重要度に応じて、開発作業に優先順位を付ける「開発案件3分割の術」はエクスプレス開発のキモといえる手法。では、それを実践するうえではどのような開発体制が効果的・効率的なのだろうか？（2010/3/25） エクスプレス開発バイブル（5）： 納期・コストを削減する“開発案件3分割”の術 開発案件に含まれる
連載：アプリケーション・アーキテクチャ・ガイド2.0解説 第1回 Application Architecture Guideの概要 日本ユニシス 猪股 健太郎 2009/03/10 マイクロソフトは自社技術に関連する膨大な量の情報を公開しているが、その中に「patterns & practices」（以下、「パターンとプラクティス」）という一連の情報があるのをご存じだろうか。 「パターンとプラクティス」とは、マイクロソフト技術を使用したアプリケーションの設計と開発における推奨事項を集めたものだ。そこで公開されている情報は、マイクロソフト社内外の専門家が作成しレビューし検証したものである。従って、アプリケーションを設計・開発する際に「パターンとプラクティス」を活用すれば、プロジェクトの技術リスクを低くすることができる。 「パターンとプラクティス」では、ドキュメント、再利用可能なソース・コー
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 今回は、この連載の第1回で書いた「名前にとことんこだわるべし」の続編である。 なぜ17回もたってから続編かというと、「名前にとことんこだわる」ことの重要性にあらためて気付かされる出来事が最近あったためだ。 というのは2007年も4月を過ぎて新年度となり、いくつか新入社員研修に呼ばれて行ったところ、ちょうど第1回のテーマである「名前」を考える実習の評判が良かったのである。それならば「名前を考える」をとことんやるような続編があってもいいのではないか、ということで今回の記事となった。 今回は初めに問題をまとめて出
「アジャイルソフトウェア開発の奥義」を読んで第二弾。オブジェクト指向設計の原則に関するメモです。自分で読んで思い出せるくらいの内容しかメモってないと思われるので、もっと詳しい解説が欲しければ本書を買ってください。 本書には、クラス設計の原則として5つの原則が載っています。 単一責任の原則 (The Single Responsibility Principle: SRP) オープン・クローズドの原則 (The Open-ClosedPrinciple: OCP) Liskovの置換原則 (The Liskov Substitution Principle: LSP) 依存関係逆転の原則 (The Dependency Inversion Principle: DIP) インターフェース分離の原則 (The Interface Segregation Principle: ISP) パッケー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く