9. http://biki.jp.net/enterprisenet レイヤ構造の分割 レイヤ 説明 プレゼンテーション プレゼンテーションレイヤでは、ユーザへのデータの表示や 入力を受け付けるための機能が実装され、Web Ｆｏｒｍｓや Windows Ｆｏｒｍｓが主要な技術になります。 ビジネス ビジネスレイヤは、ビジネスルールやビジネスロジックの機 能が実装され、トランザクションやデータ操作が主要な技術 になります。また、プレゼンテーションレイヤや他システムに サービスを提供する機能が実装されます。 データ データレイヤは、RDBへのアクセスや他のサービスを利用 する機能が実装されます。 共通基盤 共通基盤では上記の全てのレイヤで関連するセキュリティ やログ、例外などの処理を提供します。アプリケーション開 発キットに実装され提供されます。 11. http://biki.jp.net

例外設計の話。 こんな指針がいいのかなー 2013 夏 ver. 例外の目的とは？ 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」 via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html .NET の「例外のデザインのガイドライン」にもこう書いてある。 特定の例外が特定のコンテキストでスローされる理由を把握できている場合は、その例外をキャッチするようにしてください。 回復可能な例外だけをキャッチする必要があります。たとえば、存在しないファイルを開こうとした場合に発生する FileNotFoundException は、アプリケーションで処理できる例外です。それは、アプリケーションがユーザーに問題を知らせ、ユーザーが別のファイル名を指定したり、ファイルを作成したりできるようにすることが可能だからで

1. 例外設計 における大罪 和田 卓人 (a.k.a id:t-wada or @t_wada) Jun 27, 2012 @ java-ja 12年6月28日木曜日 2. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ･クエスト株式会社 取締役社長 12年6月28日木曜日

はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて

エラーハンドリングについて エラー設計なんてまともにやったことないので、 勉強してみようと思いチラチラWEBをみて集めた記事です。 「老プログラマの備忘録より」 http://a-programmer.blog.so-net.ne.jp/2007-01-30-1 「エラー処理設計：対処方法をシステム全体で定める」 http://www.st.rim.or.jp/~k-kazuma/SD/SD561.html エラー処理の方針を基本設計の段階でやっておかないと プログラマが適当にエラー処理を書いてしまうもんだから可読性が悪くなる。 ということで、コードの書き方とかエラー処理の仕組みが云々以前に エラーの種類やレベル、対処方法を整理して体系立てて設計することの重要性を感じました。

If you were looking for MSDN or TechNet blogs, please know that MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. How to use this site Archived blogs are grouped alphabetically by the initial letter of the blog name. Select the initial letter from the TOC to see the full list of the blogs. You can also type the name of the blog or the title of the

システムのリソースを柔軟に増やすことができ、従来にない拡張性を実現できるクラウド技術。その特性を生かすには、独特の設計ノウハウが必要です。 そこでここでは、さまざまなクラウド技術の設計ノウハウを、「デザインパターン」としてまとめます。各種のクラウド技術の制約をうまく回避し、性能を引き出す技や、パブリッククラウドでのコスト削減術を、設計のパターンとして示します。 Force.com編 Windows Azure Platform編 Google App Engine編

バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門（＠IT） バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え

まず最初のエントリでは、「エラーチェック」とひとくくりにされている「エラー」を、体系的に分類することを試みてみます。このエントリでは、Web / Windows、あるいは Java / .NET などといった技術論とは無関係な部分についての解説を進めていきたいと思います。 エラーチェック（ユーザ入力検証）の意味 正常終了／業務エラー／システムエラーの分類 業務エラーの細分化 アーキテクチャから見たエラーチェックの実装場所 ※ なお、本エントリで解説されている分類方法や命名方法は、あくまで nakama 個人の考え方・整理方法です。もしかしたらもっとよい設計パターンなどがあるかもしれませんので、その辺についてはあしからずご了承ください；。 ［エラーチェック（ユーザ入力検証）の意味］ まずは、そもそもどのようなケースでエラーチェックが必要になるのか、ユーザ入力検証にどのような目的があるのかを考

重要なお知らせ： この記事で公開した情報は，AndroidのMVCフレームワーク「Android-MVC」の機能の一部として取り込まれました。 より正確な設計情報や，動作可能な全ソースコードを閲覧したい場合，「Android-MVC」の公式ページより技術情報を参照してください。 AndroidのMVCフレームワーク - 「Android-MVC」 http://code.google.com/p/android-mvc-... マルチスレッドの処理を，シングルスレッドであるかのようにコーディングしたい場合がある。 １番目の非同期タスクの処理結果を，２番目の非同期タスクが利用する場合など。 つまり，並列化されたタスクを，取扱い上は「逐次化」したいのだ。 まずは手っ取り早く，やりたい事をUMLで表現しよう。 「非同期タスクの連鎖」を実装する際， しばしば下記のような「コールバックの入れ子」が生