【Patterns & Practices】Smart Client Architecture and Design Guide:
Chapter 1 - Introduction: What Is a Smart Client?

まずはスマートクライアントとは何ぞや？というところからです。

この辺りはわざわざ英語のドキュメントを読むより、日本語記事のほうがわかりやすそうですね。以下、参考文献です。

ファットからスマートへ進化する企業システムのクライアント - @IT
http://www.atmarkit.co.jp/fdotnet/special/smartcli/smartcli_01.html

スマート・クライアントの傾向と対策 - @IT
http://www.atmarkit.co.jp/fdotnet/special/smartstrtg/smartstrtg_01.html

あちこちに書かれているお決まりの話ではあるものの、
スマートクライアント登場の背景をまとめてみました。

【ファットクライアントアプリケーション】
クライアント上で動作するスタンドアロンアプリケーション。1990年代中頃が全盛期。
ネットワーク上にデータベースを配置し、複数のクライアントアプリケーションから利用するようにしたC/Sシステムや、DCOMを利用してリモートオブジェクトを参照するようなシステムもこの部類に含まれる。

■メリット
・ローカルマシンのハードウェアリソースを活用できる。
・ローカルマシンのOS(Windows)の機能を活用できる。

■デメリット
・クライアントへの配布が大変。
・配布したアプリケーションのメンテナンスが大変。（複数のアプリケーションが共通のコンポーネントやライブラリを参照していた場合に、共通のコンポーネントやライブラリをバージョンアップすると、他のアプリケーションが動かなくなる危険性がある。）

【シンクライアントアプリケーション】
ファットクライアントアプリケーションのデメリットを解決するための代替技術として、
Webブラウザベースのアプリケーションが台頭するようになる。

■メリット
・アプリケーションのロジックをWebサーバーで集中管理するため、配布の必要がなくなる。メンテナンスも楽になる。

■デメリット
・インターネットに接続していなければアプリケーションを使うことができない。
（接続が切れてしまった場合は、再入力しなければならない。）
・ファットクライアントアプリケーションに比べてユーザビリティが低下する。
（ドラッグ＆ドロップができない、アンドゥができない、などなど）
・頻繁にサーバーにリクエストを送信するため、ファットクライアントアプリケーションに比べてユーザーの待ち時間が増加する。

【スマートクライアントアプリケーション】
スマートクライアントアプリケーションは、前述のファットクライアントアプリケーションとシンクライアントアプリケーションの良いところを合わせ持ったものだとしている。

■スマートクライアントアプリケーションの特徴

1. ローカルリソースの利用
スマートクライアントはローカルマシン上で実行される。そのため、ローカルマシンのハードウェアリソース、ソフトウェア、アプリケーションを有効活用することができる。

2. ネットワークリソースの利用
スマートクライアントはネットワーク上の異なるサービスやデータにアクセスすることができる。ネットワーク上に公開されたWebサービスにアクセスすることもできるし、ビジネスロジックをサーバーで一元管理することでアプリケーションの配布やメンテナンス容易にすることもできる。

3. 非接続ユーザーへの対応
一時的にネットワークに接続していないユーザーであっても、操作を継続することが可能である。オフラインの時は更新したデータをクライアント側に保存しておき、ネットワークに接続できる状況になったらオフラインの時に入力したデータをサーバー側に反映させれば良いのだ。

4. 洗練されたインストールとバージョンアップ
スマートクライアントのデプロイ方法は何通りか考えられる。
単純にソースコードをローカルマシンにコピーする方法から、ノータッチデプロイメントを利用して中央のサーバーから自動的にソースコードをダウンロードする方法、Windowsインストーラーパッケージを配布する方法などなど。
ユーザーの要求に合わせて最適なデプロイ方法を選択すれば良い。

5. クライアントデバイスとの容易な連携
スマートクライアントアプリケーションはデスクトップPCやノートPCに限られている訳ではない。タブレット用のスマートクライアントアプリケーションや、携帯端末用のスマートクライアントアプリケーションを作成することもできる。

それにしても、1章の1節を読むだけで、こんなに辛いなんて。日本語プリーズ。

【参考資料】
(英語)Smart Client Architecture and Design Guide: Chapter 1 - Introduction
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scag-ch01.asp

投稿者: mojao 日時: 16:44 | コメント (0) | トラックバック (0)

スマートクライアントアプリケーションを構築しようと思い立ってみたものの、
どんなアーキテクチャにしたら良いものか悩んでしまいます。

書籍やインターネットを探してはみたものの、設計の観点から解説している記事はなかなか探せず。（私が知らないだけかもしれませんが。）

そして、行き着いたのがこのページ。

Smart Client Architecture and Design Guide
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/SCAG.asp

「スマートクライアントアーキテクチャ設計ガイド」とでも訳せばいいのでしょうか。

なかなか役に立ちそうな内容が書いていそうなのですが、いかんせん英語・・・。
う～ん、日本語の翻訳記事はないのでしょうか。
膨大な記事があるのは素晴らしいのですが、探すのに苦労してしまいます。

もともと、「patterns & practices」は過去の成功事例をマイクロソフトのスーパー技術者達がパターン化して文章に落としてくれたもの。ノウハウがたくさん詰まっているはずです。

このガイドは、スマートクライアントのアーキテクチャや設計に関する問題点を解決する方法、つまりベストプラクティスを提供してくれているようです。

仕方がない、読みますか・・・。
すでに日本語にしてくれてそうな人、誰かいそうなんですけどねぇ。むむむ、誰かぁ。

【参考資料】
(英語)Smart Client Architecture and Design Guide
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/SCAG.asp

投稿者: mojao 日時: 19:12 | コメント (0) | トラックバック (0)

強盗殺人を犯してしまった兄。
そのせいで、いわれのない差別を受け、苦境に立たされる弟。

弟は次第に周囲の人間からはなんとなく距離を置かれ、家を追い出され、バンドを辞めさせられ、恋人を失い、職も変えなければいけなくなる。
弟の妻と娘も周囲から避けられ、居場所がなくなっていく。

私は思う。
兄の罪を弟が償う必要なんてない。
動機が何であろうと罪を犯したのは兄であり、弟ではない。
もちろん、弟の妻と娘も関係ない。

ある人は言う。
「大抵の人間は、犯罪からは遠いところに身を置いておきたいものだ。・・犯罪者やそれに近い人間を排除するというのは、しごくまっとうな行為なんだ。自己防衛本能とでもいえばいいのかな。」

もうそれは逃れられない人間の業としか言いようがない。
ただ道徳的な観点から人は露骨にそれを態度に示したりはしないだけだ。

では、弟はどうすればいいんだろうか。
私はその不当な扱いに対する怒りを
生きていくエネルギーに変えるしかないのではないか、と思う。

弟にとって度重なる仕打ちはやはり不当なものであり、当然のものではない。
しかし、差別の原因が人間が生きていくための防衛本能にある以上、
いくら嘆いていても差別がなくなることはないのである。

この本を読んでも私は泣けなかった。
どこで泣いたら良いのかもよくわからなかった。

でも、面白かった。考えさせられる作品だった。
非常に重いテーマを扱っているにも関わらず、
最後まで読者を引き込み続ける著者の筆力には本当に感嘆する。

色々な立場の人間と自分を重ねながら、是非一度本書を読んでみてほしいと思う。

投稿者: mojao 日時: 03:50 | コメント (0) | トラックバック (0)

シリーズも4作目に突入です。

第1部はセキュアWebアプリケーションの基礎ということで、IIS, ASP.NET, SQL Serverの認証方法について解説しています。
第2部はソリューション構造やビルド・リリース、VSSを利用したソースコード共有など、主に開発環境構築について解説しています。そして、何故か途中で性能テストについても取り上げています。

サブテーマが「セキュアアプリケーション設計編」なのに書籍の内容が統一されていないのがちょっと気になりました。関連がないというか、脈絡がないというか・・。

ただ、他の書籍は取り上げないか、数ページで終わるであろう開発環境構築の指針についてこれだけ解説している書籍は他にないかもしれないですね。セキュリティに関しても難しくなりがちなところを、わかりやすく説明しています。

.NETの書籍達の中でもこのシリーズは群を抜いて面白いなぁと改めて思うのでした。

投稿者: mojao 日時: 22:39 | コメント (0) | トラックバック (0)

.NETアプリケーションを構築する場合、本格的な開発に入る前に
ソリューション・プロジェクトの構造を明確にしておく必要があるだろう。

では、ソリューションやプロジェクトはどの単位で分割すれば良いのか。
ソリューション・プロジェクトを分割した場合のメリット、デメリットをまとめてみた。

【ソリューションを分割】

■メリット：
・ソースコードを隠蔽できる。
他のチームに対してDLLファイルのみを配布すれば、ソースコードを隠蔽できる。

■デメリット：
・DLLの依存関係がVS上で把握できない。
ソリューションをまたがって参照設定を行う場合はファイル参照となる。
ファイル参照の場合はVS上では依存関係を把握できず、
循環参照が起こってしまったり、ビルドの順番が複雑になってしまう危険性がある。

・ソリューションの切り替えに若干の時間がかかる。
VS上でソリューションの切り替えを行うと、
ソリューションのクローズとオープンに多少の時間がかかる。

・デバッグしにくい。
別ソリューションのソースコードに対してデバッグ実行しにくい。
そのため、別ソリューションのコンポーネントに不具合があった場合に原因が特定しにくい。

【プロジェクトを分割】

■メリット：
・複数のプロジェクトから同一のプロジェクトのコンポーネントを共有できる。

■デメリット：
・ビルドスクリプトが複雑になる。
プロジェクトを分割しすぎるとDLLも増加するため、リリースのためのビルドスクリプトも複雑になる。

【分割指針】

ソリューションは以下のような積極的な理由がない限り分割しない。
・開発拠点が分かれていてソースコードをネットワークを経由して一元的に管理すると
開発効率が落ちてしまう場合
・ソースコードを他チームに開示したくない場合
・リリースの単位が異なる場合

プロジェクトは業務ごとにWeb層、BL層、DA層のレイヤーでプロジェクトを分割する。
・ただ、.NETエンタープライズWebアプリケーション開発技術大全〈Vol.4〉セキュアアプリケーション設計編では、上記の分け方は正しくないとしている。
-------------------------------------------------------------------
（以下、書籍から引用）
なぜなら、仮にビジネスロジックをクラスライブラリプロジェクトとして分けたとしても、実際のアプリケーションのビルドやリリース、配置作業は「業務アプリケーションA」というソリューション単位で行われるためである。つまり、せっかくアセンブリを分割しても、それらのアセンブリが個々に取り扱われることがないのである。
-------------------------------------------------------------------

でもでも、例えば・・・

・開発時には個々の開発者がプロジェクト単位でビルドを行う場合もある。
自分と関係のないコンポーネントがプロジェクト内に含まれていると、
自分と関係のないところでコンパイルエラーが発生したりして、進捗上の障害となる場合もある。
（いやもちろん、コンパイルエラーのあるソースコードはチェックインしないように
徹底すればいいんだけどさ）

・VSSにプロジェクトファイルを含める場合、クラスの追加のたびにプロジェクトファイルをチェックアウトする必要があるため、あまり分割しなさすぎるのは不便。

なんてことがあるかもしれないので、ある程度分割しておいても良いんじゃないだろうか。
・・・と思うのは私だけですかね。

【参考資料】
（書籍）.NETエンタープライズWebアプリケーション開発技術大全〈Vol.4〉セキュアアプリケーション設計編

投稿者: mojao 日時: 22:26 | コメント (0) | トラックバック (0)

ループ内でString.IsNullOrEmptyを使ってnullの判断を何回も行うと、NullReferenceExceptionが発生します。どうやらバグのようです。

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=113102

いや、まさに、I am shocked!!!!

String.IsNullOrEmptyは引数の文字列がnull又は空文字の場合にtrueを返してくれるメソッドで、私もよく使っていました。それなのに・・。

NullReferenceExceptionを起こさないためにnullチェックしてるのに、
チェックしてる君自身がNullReferenceExceptionを出してどーすんだ。

【再現方法】

1. C#コンソールアプリケーションプロジェクトを作成。
（今回のバグはコンソールアプリケーションに限った話ではないです。念のため。
ちなみに、C#でなくてもVBでも発生すると思われます。）

2. ループ内でString.IsNullOrEmptyメソッドを呼び出す。

static void Main(string[] args)
{
Console.WriteLine("starting");
test(null);
Console.WriteLine("finished");
Console.ReadLine();
}

static void test(string x)
{
for (int j = 0; j < 100; j++)
{
if (String.IsNullOrEmpty(x))
{
//TODO:
}
}
}

3. コードの最適化をONにして（デフォルトでON)、ビルドのモードをリリースビルドに設定

※リリースビルドの設定はメニューの[ビルド]-[構成マネージャ]を開いて、
対象プロジェクトの構成を「Release」に変更。

4. デバッグなしで実行（Ctrl + F5)

5. コンソールにNullReferenceExceptionがぁ！！！

-----------------------------------------------------
starting

ハンドルされていない例外: System.NullReferenceException: オブジェクト参照がオブジェクト インスタンスに設定されていません。
-----------------------------------------------------

ちなみに、String.IsNullOrEmptyを呼び出しているIf文の中で記述する処理によっては、
例外が発生しないケースもあるそうな。

回避策としては、String.IsNullOrEmptyを使わず、自分でIsNullOrEmptyメソッドを作るしかないのか。しかし、ありえんよ。ほんと。

投稿者: mojao 日時: 22:09 | コメント (0) | トラックバック (0)

SQL Serverには2つの認証方式があります。

1. Windows統合認証
2. SQL Server認証

Javaから.NETに移行した開発者の方々は、Windows統合認証に馴染みがないのではないでしょうか。

.NETエンタープライズWebアプリケーション開発技術大全〈Vol.4〉セキュアアプリケーション設計編では以下のように
説明されています。<<以下、書籍から引用>>
-----------------------------------------------------
■Windows統合認証
ASP.NETアプリケーションのワーカープロセスを動作させているWindowsユーザーアカウントを利用して、SQL Serverに接続する方式

■SQL Server認証
SQL Server上に独自に定義されたユーザーアカウント(SQL Serverログインアカウント）
を明示的に指定して、SQL Serverに接続する方式。

------------------------------------------------------

SQL Server認証は、OracleやPostgreSQLに接続する方式と大差ありません。
（接続文字列はDBMSごとに異なりますが。）

Data Source=(local); Initial Catalog=pubs; User Id=sa; Password=pass;

あらかじめデータベース上に定義しておいたユーザー名とパスワードで
データベースに接続しにいきます。

それに比べて、Windows統合認証にはユーザー名やパスワードが必要ありません。

Data Source=(local); Initial Catalog=pubs; Integrated Security=True;

では、どうやってSQL Serverは認証を行うのでしょう。

Webアプリケーションの場合、SQL ServerはASP.NETを動作させているユーザーで認証を行います。タスクマネージャのaspnet_wp.exe、またはw3wp.exeのプロセスのユーザー名がそれにあたります。

Windows統合認証にするメリットは、接続文字列にパスワードが含まれなくなるので、パスワードが盗まれるリスクが少なくなります。
SQL Server認証の場合、接続文字列はデフォルトでapp.configに出力されると思いますが、app.configは多くの開発者が目にするファイルなので、接続文字列を暗号化するか、レジストリなどに移動する必要があります。

ただし、Windows統合認証の場合には、Webサーバー⇔DBサーバーの間に
DB接続ポート以外にWindows統合認証用のポートを空けなければなりません。
また、WebサーバーとDBサーバーを同一のドメインに含めなければなりません。

上記の事項がインフラ上の制約やセキュリティポリシーに違反する場合には、
必然的にSQL Server認証を使うことになるでしょう。

【参考文献】
（書籍）.NETエンタープライズWebアプリケーション開発技術大全〈Vol.4〉セキュアアプリケーション設計編

投稿者: mojao 日時: 19:06 | コメント (0) | トラックバック (0)

DataSetのGetChangesメソッドを使用すれば、
DataSetから変更行だけを抽出できます。

多階層アーキテクチャの場合にDataSetの全行を受け渡すと
システム間の転送量が多くなってしまい、性能に影響が出る場合があります。
そんな時、DataSet.GetChangesメソッドは役に立ちます。

例えば、更新ロジックの場合、以下のような使い方をすることになります。

PL層：DataSet.GetChangesで修正行のみを取得し、BL層に渡す。
BL層：受け取ったDataSetをDA層に渡す
DA層：受け取ったDataSetをxxxTableAdpater.Updateメソッドなどで更新。

ところで、xxxTableAdapter.Updateには更新後に最新の値を
DataSetに書き戻してくれる機能があります。
例えば、更新前に自動採番列に値が入っていなかったとしても、
更新後に自動採番された値をDataSetに書き戻してくれたりします。

更新後の値を全行格納されたDataSetに反映したい場合には、
DataSet.Mergeメソッドを使用すればＯＫです。

主キーが同じ行に対して最新の値を上書きすることができます。
（主キーがDataSetに設定されていることが前提ですが。）

dataSet1.Merge(dataSet2)

上記のように書けば、dataSet1にdataSet2の値をマージしてくれます。

【参考文献】

プログラミングMicrosoft ADO.NET

投稿者: mojao 日時: 01:14 | コメント (0) | トラックバック (0)

このシリーズは本当に面白いです。

Vol.3 ASP.NET応用編の章構成は以下のようになっています。

1章：Webシステムのスケーラビリティとクラスタリング
2章：Webアプリケーションの状態管理
3章：ASP.NETランタイムの詳細動作
4章：デバッグ、トレース、例外処理
5章：ASP.NET Webアプリケーションの構成管理

4章（特に前半）はWebアプリケーションに限った話ではないので、Windowsアプリケーションを開発しようと思っている方にとっても有益だと思います。

すぐにプログラムを書きたい人にとっては、もしかしたらつまらないかもしれませんが、内部の動作の仕組みを理解することは品質の高いアプリケーションを作る上で欠かせません。

Vol.が進むにつれ応用編になり、扱う内容の難易度もあがりますが、丁寧に1つ1つ説明されているので、とてもわかりやすいです。

「とにかくこう書けば動く」という覚え方では応用が利かないですし、トラブルが発生した場合の解決スピードにも差が出ます。もちろん、良い設計をすることも儘ならないはずです。
何故そのような作りになっているのかを考えることはとても大切なことであり、原理原則を押さえておくためにも、腰を据えてじっくり本書を読んでみてはいかがでしょうか。

投稿者: mojao 日時: 22:27 | コメント (0) | トラックバック (0)

Javaでは検査例外と実行時例外の2種類の例外をサポートしています。
検査例外はメソッドの後ろにthrowsで例外の型を定義しておきます。
呼び出し側のクラスで適切な処理がなされていない場合はコンパイルエラーが発生します。

ただ、.NETの場合には検査例外がサポートされていません。
これは、例外に関する設計方針を検討する際にも影響を与えます。

Javaで業務エラーが発生した場合には、独自の検査例外をthrowさせ
上位のコンポーネントに処理を促す仕組みにしている場合が多々あります。

一方、.NETでは業務エラーが発生した場合には、基本的に戻り値で対応します。
必要なエラー情報が全て格納できるような戻り値を検討することになると思います。

つまり、.NETの場合は以下のように、例外が発生した時に何らかの処理を行いたい場合のみ例外をキャッチします。この「のみ」というのが重要で、ほとんどの場合は例外をキャッチするコードは必要なく、上位のコンポーネント（イベントハンドラ）がキャッチしてくれるのを期待するだけです。

・ログの記録のための情報を集める場合
（ログ出力する際に必要な情報が例外が発生したクラスでしか取得できない場合は、下位のコンポーネントで一旦例外をキャッチし、必要な情報を詰めたのち再スローするなど）

・正常系の処理に復旧したい場合
基本的に例外が発生した場合の処理は上位コンポーネント（イベントハンドラ）で一元管理するが、例外を例外として扱わず、正常系の処理に戻したいという要件がある場合には、例外をキャッチして復旧処理を記述する。

これにより、ソースコードの見通しがよくなるというメリットがあります。
また、開発者が似たような例外処理を記述する必要がないという点もあげられます。

Javaで開発する際は細かく例外クラスを定義したりすることもありますが、
実際のところ、キャッチ節でほとんど処理することがなく（またはそのクラスでは対応できなく）上位コンポーネントに再スローするだけの記述が多くなってしまいます。

JavaではSQLExceptionは検査例外として定義されていますが、最近(?)ではHibernateでもSQLExceptionを内部でキャッチして実行時例外にラッピングしてスローするなど、下位コンポーネントでは例外を気にすることなく処理できるような仕組みになっています。

.NETで開発する場合、アプリケーション開発者は例外をキャッチしてはいけない。ぐらいのコーディング規約があっても良いと思う今日この頃なのでした。

## ちなみに、なぜ.NETでは検査例外がサポートされていないのか。
上記のような例外に対する思想の違いと、.NETは多言語対応なので検査例外の仕組みを作るのは難しいというのが理由のようです。

【参考文献】

（書籍）.NETエンタープライズWebアプリケーション開発技術大全〈Vol.3〉ASP.NET応用編

.NETにおける例外管理
http://www.microsoft.com/japan/msdn/net/bda/exceptdotnet.aspx

投稿者: mojao 日時: 13:04 | コメント (0) | トラックバック (0)

ASP.NETではセッションの保持方法として以下の3つがサポートされている。

【InProc】セッション情報をWebサーバーと同マシン上のメモリ内に格納する方式（デフォルト）

■メリット
・3つの方法の中では一番パフォーマンスが良い。

■デメリット
・Webサーバーの障害時、再起動時にセッションの情報が削除されてしまう。

・複数のWebサーバーからにセッション情報を共有できない。
そのため、複数のWebサーバーを並列に繋げて、リクエストごとに別のサーバーに振り分けるような構成にした場合に、セッション情報を引き継ぐことができない。

【StateServer】セッション情報を別サーバーのメモリ内に格納する方式

・外部サーバーの起動コマンド：net start aspnet_state
※ ステートサービスは.NET Frameworkをインストールする際に一緒にインストールされる。

・web.configのsystem.webセクションに以下のような記述が必要。

<sessionState mode="StateServer"
stateConnectionString="tcpip=[サーバー名]:42424"
cookieless="false"
timeout="20/>

■メリット
・Webサーバーの障害時、再起動時であってもセッションの情報が失われない。

■デメリット
・ステートサーバーそれ自体をクラスタリングすることができないため、
ステートサーバーに障害が発生した場合にシステムが稼動できなくなる。

【SQLServer】セッション情報を別サーバーのデータベース内に格納する方式

・InstallSqlState.sql、又はInstallPersistSqlState.sqlを利用して
SQLServerにセッション格納用データベースを作成する必要がある。
（InstallSqlState.sqlの場合はSQLServer再起動時にセッションが削除されてしまう。）

・InstallSqlState.sqlでデータベースを作成した場合には
ASPStateデータベースにはセッション情報を処理するためのストアドが登録され、
実際のセッションの値はtempdbデータベースに格納される。

・web.configのsystem.webセクションに以下のような記述が必要。

<sessionState mode="SQLServer"
sqlConnectionString="data source=127.0.0.1;user
id=;password="
cookieless="false"
timeout="20"
/>

■メリット
・Webサーバーの障害時、再起動時であってもセッションの情報が失われない。

・DBサーバーを冗長構成にしておけば、1つのDBサーバーに障害が発生した場合でも
もう一方のDBサーバーで稼動を続けることができる。

■デメリット
・InProcに比べれば処理速度が遅い（ただし、セッションサイズに大きなデータを格納しなければ問題ない場合も多い）

【その他の注意点】
※StateServerとSQLServerモードではシリアライズ可能なオブジェクトしかセッションに格納することができない。（シリアライズ不可のオブジェクトを格納すると実行時エラーとなる。）
本番でStateServer又はSQLServerモードにするのであれば、開発時はStateServerモードにしておくこと。（InProcモードではシリアライズ不可のオブジェクトを格納してもOKなので、開発者が気づきにくい。）

※.NETに限らずですが、セッション情報はサーバー内に格納されるため、サイズの大きいオブジェクトを格納するとパフォーマンスの低下につながってしまう。
（クライアントはクッキー情報にセッションIDを持っているだけ。）
セッションのサイズをチェックできる仕掛けを共通機能として組み込んであげると良いですね。

【参考文献】
（書籍）.NET エンタープライズWebアプリケーション開発技術大全　Vol.3

[HOWTO]SQL ServerでASP.NETセッション状態管理を構成する方法
http://support.microsoft.com/kb/317604/ja

投稿者: mojao 日時: 15:12 | コメント (0) | トラックバック (0)

ハードウェアを拡張する場合、WebサーバーとDBサーバーでベターな拡張方法が異なる。

【Webサーバー】スケールアウトのほうがよい。

理由：
・スケールアップによる増強を行っても、ある時点でパフォーマンスがあがらなくなる。
（メモリやハードディスクなどの共有リソースで競合してしまうため。増強するならば、
4CPUぐらいまでが効果が高い。）

【DBサーバー】スケールアップのほうが良い。

理由：
・スケールアウトしてDBサーバーの台数を増やすと、設計・実装の難易度が格段に上がる。
（更新系の処理はトランザクション処理やデータの同期など特に難しくなる。）

・複数のプロセスが参照する共通のテーブルも多々あるため、
完全にデータベースを分離するのが難しい。
複数のマシンに対して通信処理が必要になると逆にパフォーマンスの低下につながる。

※スケールアウト：マシン台数を増やし負荷分散を行う。
※スケールアップ：サーバーの台数を変えずに、CPU増強、メモリ増設などを行う。

【参考文献】

（書籍）.NETエンタープライズWebアプリケーション開発技術大全 Vol.3

スケールアウトとスケールアップ：サーバー処理能力向上の2つのアプローチ
http://japan.zdnet.com/sp/feature/06sp0130/story/0,2000066437,20234267-2,00.htm

投稿者: mojao 日時: 14:07 | コメント (0) | トラックバック (0)

DataRowはシリアライズできません！！

知りませんでした。知りませんでした。
いや、だって、DataSetは普通にシリアライズできるんですよ。

シリアライズできないということは、ViewStateやセッションにそのまま格納できないです。
（セッションをステートサーバーやSQLサーバー上に持つ場合、
シリアライズできないオブジェクトを格納することはできません。）

メソッドの引数にも渡さないほうが良いですね。
別マシンから呼び出される可能性も考慮すると、特にレイヤをまたがるメソッドの引数にシリアライズできないクラスを定義するべきではないです。

ちなみにDataTableはシリアライズできるのでしょうか。
試してみました。できますね。
どうやら、バージョン2.0になってできるようになったみたいです。

しかし、何故できないのでしょう。できても良さそうなのに。
ぼちぼち調べてわかったらまた書きます。

投稿者: mojao 日時: 02:08 | コメント (0) | トラックバック (0)

Webアプリケーションを構築する場合、論理階層（レイヤー）はプレゼンテーション層(PL)、ビジネスロジック層(BL)、データアクセス層(DA)の3階層とするのが一般的かと思います。

一方、物理階層（ティア）は2階層 or 3階層のどちらかだと思います。
論理階層が3階層だからといって、物理階層も3階層にする必要はありません。
物理階層は2階層のほうが開発・運用におけるメリットが大きいので、
3階層にする必要が本当にあるのかシステム要件をもとに十分検討する必要がありそうです。

【2階層】
構成：Webサーバー(PL, BL) → DBサーバー(DA)

■ メリット
・拡張（クラスタリング）が楽。
（3階層の場合はWebサーバーとAPサーバーの負荷が均一になるよう検討が必要）
・開発が楽。
（3階層の場合はWebサーバーからAPサーバーへの通信処理の実装や、認証方法の検討などが必要）
・運用が楽。
(WebサーバーとAPサーバーでは監視項目や運用手順が異なるので、3階層の場合は運用方法を別々に検討する必要がある）

■ デメリット：
DBサーバーへの接続に必要なポートを内部FWに空けなければならない。

【3階層】
構成：Webサーバー(PL) → APサーバー(BL) → DBサーバー(DA)

■ メリット：
・内部FWの内側にAPサーバーを置ける
（ビジネスロジック自体が重要なシステムの場合には
内部FWの内側に置き、不正な侵入を防ぐことに価値がある）

■ デメリット：
・WebサーバーからAPサーバーへの呼び出しにおける通信コストの増大
（同一プロセス内の呼び出しに比べて、別マシン上の別プロセスの呼び出しは圧倒的に遅い）

【参考文献】

（書籍）.NET エンタープライズWebアプリケーション開発技術大全 Vol.3

アプリケーション・アーキテクチャ設計入門
http://www.atmarkit.co.jp/fdotnet/architecture/aafn05/aafn05_01.html

投稿者: mojao 日時: 17:24 | コメント (0) | トラックバック (0)