Home > プログラミング > C#.NET Archive

C#.NET Archive

Obsolete属性

  • Posted by:
  • 2008年4月14日 17:52
  • C#.NET

.NETを使っていると、たまに「古いバージョンなので推奨しません」みたいな警告が出るのですが、同様のことを Obsolete属性で実現できるようです。
一応の互換性は保ちたいものの、徐々に新モジュールに置き換えていきたいときなどに便利ですね。

Obsolete (C# プログラミング ガイド)

Obsolete 属性によって、プログラム要素が、使用を推奨されない要素としてマークされます。要素に Obsolete とマークするたびに、属性の設定内容に応じて、警告やエラーが生成されます。次に例を示します。

コードのコピー
[System.Obsolete("use class B")]
class A
{
public void Method() { }
}
class B
{
[System.Obsolete("use NewMethod", true)]
public void OldMethod() { }
public void NewMethod() { }
}

この例で、Obsolete 属性は A クラスと B.OldMethod メソッドに適用されています。B.OldMethod に適用されている属性のコンストラクタで、2 つ目の引数が true に設定されているため、このメソッドを使用するとコンパイラ エラーになり、A クラスを使用すると単に警告が生成されます。一方で、B.NewMethod を呼び出しても警告やエラーは生成されません。

属性のコンストラクタで、1 つ目の引数として指定された文字列は、警告またはエラーの一部に表示されます。たとえば、次のコードを前の定義と共に使用すると、2 つの警告と 1 つのエラーが生成されます。

コードのコピー
// Generates 2 warnings:
A a = new A();
// Generate no errors or warnings:
B b = new B();
b.NewMethod();
// Generates an error, terminating compilation:
b.OldMethod();

A クラスでは 2 つの警告が生成されます。1 つはクラス参照の宣言、もう 1 つはクラスのコンストラクタで生成されます。

Obsolete 属性は引数なしでも使用できますが、その項目の使用が推奨されない理由と代わりに使用する項目を引数に指定することをお勧めします。

Obsolete 属性は、シングルユースの属性です。属性を使用できる任意の要素に適用できます。Obsolete は、ObsoleteAttribute のエイリアスです。


NClass

  • Posted by:
  • 2007年11月 4日 16:22
  • C#.NET

NClass

C#用にクラス図を描きたいとき、Visioとかだとコード生成機能が無いので不便だなあと思っていたのですが、NClassはきちんとソースコードを生成してくれます。
ツールのメニューは日本語対応していませんが、UMLでは問題なく使用できるっぽいです(少なくとも私の環境では大丈夫でした)。
オープンソースなので、どうしても日本語じゃなきゃヤダという人もなんとかできますね。

ツールの使い勝手も良く、特に使用方法を調べなくても勘でどうにかなる感じです。

お勧めです。

旧暦月日

JapaneseLunisolarCalendar クラス


JapaneseLunisolarCalendar クラスは、太陰太陽暦を表す EastAsianLunisolarCalendar クラスから派生しています。EastAsianLunisolarCalendar クラスでは、太陽暦と、太陰太陽暦、年が時代 (年号) に関連付けられ 60 年周期を持つ暦、および年の任意の月の後に閏月を置くことができる暦との間の日付の変換がサポートされます。

閏月は、年の任意の月の後に置くことができます。たとえば、GetMonth メソッドは、特定の日付に関連付けられた月を示す 1 ~ 13 の範囲の数値を返します。閏月が 8 番目の月と 9 番目の月の間にある場合、GetMonth メソッドは、8 番目の月に 8 を返し、8 番目の閏月に 9 を返し、9 番目の月に 10 を返します。

現在、JapaneseLunisolarCalendar は CultureInfo クラスがサポートしているどのカルチャでも使用されていません。したがって、このクラスは、日本の太陰太陽暦での日付を計算するためだけに使用できます。

各 CultureInfo は一連の暦をサポートしています。Calendar プロパティは、カルチャの既定の暦を返し、OptionalCalendars プロパティは、そのカルチャがサポートしているすべての暦の配列を返します。CultureInfo が使用する暦を変更するには、CultureInfo.DateTimeFormat の Calendar プロパティを新しい Calendar に設定します。

へえ、こういうのが用意されているのね...

タイプセーフなSession操作

  • Posted by:
  • 2007年5月 6日 16:22

ソースファイル一式

Higtyさんのオリジナル版はこちらから
[CodeZine]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成
[ひぐたぅん]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成


GW前に出来ていたのですが、アップロードを忘れていました(汗)

オリジナル版と比べて、抽象化しまくっているので構造は複雑になっていると思います。
中級者以上向けでお願いします。
あと、弁慶Frameworkに組み込むことを前提に作っていますので、namespaceは変わっています。
オリジナル版と比較される時は、そのあたりに注意してください。

実際に作ってみて、オリジナル版のシンプルさと使いやすさのバランスの良さを感じました。
弁慶Frameworkに入れるためとはいえ、ちょっといじりすぎたかもしれません。
ほとんどの場合は、オリジナル版の方が使いやすいんじゃないかと思います。


以下、説明

まず、Castクラスですが、オーバーロードを1つ増やしています。
で、オーバーロードしたメソッドを呼ぶようにしたことで、重複したコードが無いようにしました。
速度を重視すると重複して書いた方がいい訳ですが、弁慶Frameworkは速度をあまり重視していないので。
で、オブジェクトの型変換は、オリジナル版ではToStringでしたが、これだとDouble型のときに丸められてしまうため、普通(?)に型変換することにしました。
型変換に失敗すると、当然の事ながらExceptionが出ますので、呼び出し元で処理してください。
Exceptionを呼び出し元に任せるのも、弁慶Franeworkの考え方に合わせました。

肝心なSession操作ですが、機能と実装を分けています。
何故か?というと、NUnit等を使用するときSession操作が出来ないので、一時的にHashTableを使用するようにするためです。(というか、このためだけに面倒くさくなりました)
機能と実装を分けたことで、一時的に実装部分を差し替えるという訳です。
この差し替えサンプルについては、NUnitのテストクラス(SessionValueTest)を見てください。

Form、QueryStringも大体同じです。
ViewState、Cockieは、あえて操作クラスを作る必要性が無いような気がしたので、今回は作ってません。

ASP.NETのセッションをタイプセーフに取り扱うクラスの作成

  • Posted by:
  • 2007年4月 6日 00:19

CodeZineでCool!なエントリを見つけたのでご紹介したいと思います。

[CodeZine]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成
[ひぐたぅん]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成

Sessionを操作するのはHashtableのようにキーを与えてobjectで取得し、型変換処理を行う訳ですが、この方法を使うとインテリセンスが効いてくれるので、大変使いやすくなります。
ラッパークラスで吸収する形なので初心者にも分かりやすいのが素晴らしいと思います。


実は、私も同じようなクラスを作ろうと思っていたところだったのですが、いいラッピングの仕方が思いつかず今に至っておりました。
著者のHigtyさんの許可が頂けたらですが、私のやりたいことを組み合わせたカスタムバージョンを公開したいなあと思いました。

やりたいこと
・staticメソッドではなくて、クラス自体をSingletonにする
・Session、QueryString、Cookie、ViewStateのBaseクラスを作成し、サブクラスはプロパティのみの実装とする
 Sessionをひとまとめではなく、なんらかのグループで纏めたい場合もあるので、サブクラスできるのは便利だと思う
・機能と実装を分離する形で、実際のデータ取得をするクラスに委譲するようにBaseクラスを実装する
 データ取得クラスは実行時に入れ替え可能にする。そうすることでNUnit等からSessionクラスを仮想操作できる
 仮想操作用としては、Hashtableでも使えばよいと思う。

と、いったところでしょうか。
頭の中ではもうできていたりします。

なぜプログラムが追いにくいのか?

ある理由から、意味の分からないソースコード(C#)を読んでいます。
資料はそれなりに揃っているものの、ソースコード上にコメントがほとんど無く、資料と整合性が合っていない場合、なぜ違うのかが全く分からないんですよね。
かなり苦戦している訳ですが、せっかくなので、なぜ読みにくいコードになっているか考えてみようと思います。

簡単に思いつくあたりでは、
・コメントが圧倒的に足りない。というか必要なところになく、役に立たないコメントだけ存在。
・「とりあえず動けばいいや」的な場当たりな作り方。
・間違った共通化。共通ロジックの呼び出し方が暗号みたいな作りになっていた。

と、こういうのは大体どこにでも存在するコード(泣)で、どちからというとマナーみたいなもんなんですが、果たしてこれが解決すると読みやすいか?というと、そうでもない気がしてきました。
根本的な問題があるのはプログラムの構造で、モジュール分割や機能と実装の分離が正しく行われていないことが原因だと思います。


特に重要だと思うのが、機能と実装の分離です。
例えば、機能説明に「検索ボタン押下時に受注情報を取得する」と書いてあるのに、その処理を示すメソッドが「SelectOrder」となっていたとします。
これは最終的な結果から見ると正しい動作になっていますが、構造では欠陥があります。
つまり、「受注情報を取得する」をしたいときに、何故「SelectOrder」なのか関連性が不明だからなんです。
(この例は単純な例なので容易に想像できちゃいますが...)

検索ボタン押下→SelectOrder

ではありません。
この場合は、

検索ボタン押下→Get受注情報→SelectOrder

とすべきです。
なぜなら、機能説明に忠実に作成するなら、検索ボタン押下に要求される機能は「受注情報を取得する」ことだからです。
そして、「受注情報を取得する」ための実装として「SelectOrder」が呼ばれます。
このように、機能と実装を分離すると、もし実装が変わっても(例えばデータベースが変わるとか)、ボタン押下イベント側には影響が出ません。
また逆に、ボタン押下イベント側から利用する際にも、どんな実装をしているかを気にせずに呼び出すことができるようになります。

さらに付け加えると、ボタン押下イベント側から呼ばれるメソッドは、機能を表す名前をつけることが望ましいです。
なので、この例でも「受注情報を取得する」のような機能の場合、動詞を前に出して「Get受注情報」としています。


他に気をつけるべき点として、メソッドを単一機能に限定することが挙げられると思います。
つまり、メソッドの説明をするときに「このメソッドは○○と××をします」のようになってしまうのは問題があります。
正しくは、「○○をする」メソッドと、「××をする」メソッドの2つのメソッドに分割することです。
そうすることにより2つの機能が独立するため、単純な構造になります。


実はこういう事を言うと、「こんなことをしたら、クラスやメソッドがいっぱい増えて、処理が遅くなってしまう」と反論する人がいます。
これはある意味では正しいと言え、実際にクラスやメソッドが増えるし、処理も遅くなります。
しかし、オブジェクト指向言語を選択した時点で、パフォーマンスが最重要課題でない(最重要課題ならC等を選びましょう)ため、例えば0.01秒掛かっていたのが0.02秒になったとしても、実際にほとんど影響が無いと言えます。(それでも早くしたいなら、性能の良い動作環境を買ってもらいましょう)

確かにわずかながらデメリットはありますが、システムの将来を考えると、より可読性の高いコードを生産する方が価値が大きいのではないでしょうか。

LIB環境変数の警告

  • Posted by:
  • 2006年11月 7日 21:00

ビルド時に
Invalid search path 'C:\Program Files\Microsoft Visual Studio.NET\FrameworkSDK\Lib\' specified in 'LIB 環境変数' -- '指定されたパスが見つかりません。 '
の警告が出てしまうので、調べてみました。

【as blog】LIB 環境変数

どうやら、VisualStudio2002が悪さしているようですね。
アンインストールしているのですが、削除されずに残っていたようです。

【VisualStudio2005】ASP.NET開発サーバを固定ポートにする。

  • Posted by:
  • 2006年10月20日 12:16

ASP.NETのデバッグ実行時に、ASP.NET開発サーバが起動するのですが、これがランダムなポートなのでいろいろと面倒な場合があります。
(例えば、WEBプロジェクトを複数のソリューションに追加すると、ソリューションごとにポートが違ったり)
ただ、ランダムに設定されるのは初回だけで、以降は同じポートを使い続けています。
ということは、ソリューションファイルかな?ということで覗いてみました。

VWDPort = "ランダムに設定されたポート番号"
と書いてあるあたりが怪しいので、早速変更してみるとビンゴ!

※ソリューションファイルをテキストエディタで変更する方法なので、自己責任で行うようにしてください。
 何か不具合がありましても責任を取りかねます。
 念のため、バックアップしておく等の措置を行った方が良いと思います。

【ASP.NET】HyperLinkFieldでJavaScriptをリンクするとリンクが表示されない

  • Posted by:
  • 2006年9月30日 12:36

タイトルに書いたとおり、HyperLinkFieldでJavaScriptをリンクするとリンクタグが表示されなくなってしまいます。(DataTextFieldは正しく表示されます)
恐らくはクロスサイトスクリプティング対策なんでしょうが、もう少しなんか方法があればいいんですが...

<asp:HyperLinkField DataNavigateUrlFields="Url" DataNavigateUrlFormatString="javascript:hoge({0})" DataTextField="Name" />

仕方がないので、TemplateFieldに置き換えたら問題なく動きましたが、やはり面倒ですね。

<asp:TemplateField>
<ItemTemplate>
    <A id="ALinkFix" runat="server" href='<%# "javascript:hoge(" + DataBinder.Eval(Container.DataItem, "Url") + ")" %>'>
    <%# DataBinder.Eval(Container.DataItem, "Name") %>
    </A>
</ItemTemplate>
</asp:TemplateField>

【VisualStudio.NET】sealedキーワードでインライン化

  • Posted by:
  • 2006年9月 3日 13:24

第 5 章 「マネージ コード パフォーマンスの向上」
ちょっと長いドキュメントですが、「sealed キーワードの使用を検討する」の見出しの部分になります。

簡単に説明すると、仮想メソッド(virtual)をオーバーライド(override)していてもう継承する予定が無い場合、sealedを付けると高速化するというもののようです。
「クラス設計を拡張する必要がないなら、仮想メンバは使わないようにしてください。仮想テーブル検索による呼び出しの負担が大きく、実行時のパフォーマンス最適化を妨げる場合があるためです。」
と書いてあるように、仮想メソッドはオーバーヘッドが大きいようです。
sealedで明示的に終わりを宣言すると、コンパイラの最適化でvirtualなメソッドの中身をインライン化するようです。
そうすると実質的にはvirtualの呼び出しが行われなくなるので(インライン化されているから)、高速化するという理屈なんじゃないかなと思います。

微妙な高速化ですが、繰り返し処理で使われている場合は改善が見込めるかもしれません。

【ADO.NET】SqlParameterのサイズプロパティ

  • Posted by:
  • 2006年8月20日 20:57

共通的なDataAccessクラスを作成していたところ、エラーが発生したので公開します。

エラー内容
 着信の表形式のデータ ストリーム (TDS) リモート プロシージャ コール (RPC) プロトコル ストリームが不適切です。パラメータ 8 ("@HOGE"): データ型 0xE7 に、無効なデータ長またはメタデータ長が指定されています。

該当箇所のソースコードは以下のとおり


DbParameter dataParamArray = new DbParameter();
dataParamArray.ParameterName = "@HOGE";
dataParamArray.Direction = ParameterDirection.Input;
dataParamArray.Size = 8000;
dataParamArray.Value = "TEST";

プロパティをいろいろいじって調べてみると、どうやら dataParamArray.Size に大きな数値を入れると異常終了することが判明しました。
そこでMSDNで調べてみたところ、dataParamArray.Size や dataParamArray.Type は特に設定する必要は無く、dataParamArray.Value によって自動的に判別されるとのこと。
実際、dataParamArray.Sizeを削除したところ、正常に動作しました。

スキーマコレクションからテーブル一覧を取得する方法

  • Posted by:
  • 2006年8月10日 14:34

以前、SQL文を実行してSQLServer上のテーブル一覧を取得する方法を紹介しましたが、今回はスキーマコレクションから取得する方法です。

参考
SqlConnection.GetSchema メソッド
GetSchema メソッドの使用

参考の例だとSqlConnectionを使っていますが、.NET Framework version 2.0なら DbConnectionを使うこともできます。
実際に他のデータベースで試したことはないですが、テーブル情報取得のSQL文はデータベースによって大きく異なるため、結構使えるかもしれません。

Singletonパターンを使ったファイル変更監視

  • Posted by:
  • 2006年8月 8日 17:03

アプリケーション起動中、常にファイル監視をする要件があったとします。
具体的に言うと、あるファイルを常に監視し、ファイルが変更されたときに再読み込みをする等のイベントを処理させます。
実装例としては、自前で用意した環境ファイルのデータを保持するといったようなものが考えられると思います。

ファイルの監視方法ですが、FileSystemWatcherで監視するファイルを設定し、FileSystemEventHandlerでイベントハンドリングを行えばよさそうです。
こういう仕組みが備わっているのが.NETの良さですね~

FileSystemWatcher watcher = new FileSystemWatcher(ファイルパス, ファイル名);
watcher.Changed += new FileSystemEventHandler(処理したいメソッド名);

のようにすればOKです。
常時監視ということなので、監視モジュールが常にメモリにロードされている必要があります。
常時ロードとなると、ASP.NETの場合、Application_Startに記述してしまえばいいのですが、そのロジックをWindowsアプリでも汎用的に使うことはできません。

そこで、ASP.NETでも常にメモリにロードされているということで、Singleton実装にしてみました。
Singletonのそもそもの目的は、アプリケーション内で唯一存在するオブジェクトを作成するためなのですが、唯一存在させるためにインスタンスをstaticで保持しています。
そのため、Singletonのコンストラクタで上記の監視ロジックを入れておけば、常にメモリに存在することとなり、どのプログラムを実行していてもイベントが発生します。
問題点は、Singletonなので複数のファイルを監視できないことですが、そのような場合はGetInstanceの仕組みを変えてあげることで対処できそうです。

【ASP.NET】Page以外でポストバックかどうかを判別する

  • Posted by:
  • 2006年8月 3日 13:59

HttpModuleでゴリゴリやってたら、HttpModule内でポストバックの判定が必要になってしまいました。
ところが、IsPostBack()メソッドってPageにしか存在しないため使えないんですね。

仕方がないので、Page.IsPostBack()と同等の機能を実装することにします。
ポストバックとそうでないときで違うところと言えばViewStateの扱いなので、このあたりを実装すると良さそうです。
サンプルコード(C#)は下記のとおりです。
「this.httpApp」の部分は、各自の環境に合わせたHttpApplicationオブジェクトを指定してください。

#region ポストバック判定処理
/// 
/// ポストバックかどうか判定する。
/// 
/// ポストバック時は true、ポストバックではないときは falseを返します。
/// 
/// HttpModule では IsPostBack を実装していないため、「__VIEWSTATE」が Request.Params に存在するかでチェックしています。
/// 
private bool IsPostBack()
{
    try
    {
        return (this.httpApp.Context.Request.Params["__VIEWSTATE"] != null);
    }
    catch
    {
        return false;
    }
}
#endregion

オブジェクトのディープコピー

  • Posted by:
  • 2006年8月 1日 15:04
  • C#.NET

C#では(というかほとんどのオブジェクト指向言語では)、オブジェクトのCloneを行うと参照のみがコピー(シャローコピー)されます。
シャローコピーのときは、値を変更するとコピー元のデータも変更されてしまうので、オブジェクトのバックアップを取りたいときは値そのものをコピー(ディープコピー、ディープクローン)するように実装しなければなりません。

一番簡単な方法はオブジェクトをシリアライズし、それを別オブジェクトにデシリアライズすることです。
汎用的に使えるのですが、オブジェクトがシリアライズ化できる必要があります。
シリアライズ化対応でない場合、そのオブジェクトごとに値の詰め替えを実装しなければなりません。

以下、シリアライズを使用したディープコピーのサンプルです。


/// <summary>
/// オブジェクトをディープコピーする。
/// </summary>
/// <param name="source">コピー元オブジェクトを指定します。</param>
/// <returns>コピー先オブジェクトを返します。</returns>
/// <remarks>このメソッドを使用するには、対象クラスが Serializable できることが前提となります。</remarks>
public static object DeepClone(object source)
{
object target = null;
using (MemoryStream stream = new MemoryStream())
{
// コピー元オブジェクトをシリアライズします。
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(stream, source);
stream.Position = 0;

// シリアライズデータをコピー先オブジェクトにデシリアライズします。
target = formatter.Deserialize(stream);
}

return target;
}

【ASP.NET】URLの書き換え

  • Posted by:
  • 2006年7月30日 01:21

仕事でURLの置き換えをする必要が出てきたので、IHttpModuleを使用することにする。
受信フィルタとも呼ばれる仕組みらしいですが、メリットとしてはaspxの画面が開かれる前に呼ばれる点でしょう。
呼ばれたページが開かれた際にリダイレクトするより、ページが開かれる前にURLを書き換えてしまうほうが、よりスマートと言えるのではないでしょうか。

URLの置き換えを知るには、以下のページが参考になると思います。
ASP.NET での URL 書き換え
MSDN:特集2.NET実践プログラミング PartVII ASP.NET ISAPIとASP.NETのもとでHTTPフィルタを使ってWeb要求を横取り,監視,変更する
URL Mapping for ASP.NET 1.1
ASP.NET 2.0: Rewriting URL Paths just got a whole lot easier
ASP.NET 2.0: URL Mapping with RegEx Support

また、URLの書き換えだけでなく、HTTPモジュールについても知っておく必要があります。
HTTP モジュールの概要
方法 : カスタム HTTP モジュールを作成する
ASP.NET アプリケーションのライフ サイクルの概要
@IT:[ASP.NET]アプリケーション共通のロギングを行うには?(HTTPモジュール編)

HTTPモジュールを使うとして、問題になりそうなのが単体試験をどうやってやるかってことなんですが、
Visual C# .NET を使用して ASP.NET HTTP モジュールを作成する方法
テスト方法が載っているけど、こういう方法じゃ単体テストとは言えないですね。
NUnitAspを使う方法で考えてみようと思います。

【デザインパターン】C#でのシングルトンの実装

  • Posted by:
  • 2006年7月19日 13:30

システム内部で唯一のインスタンスがほしいときは、Singletonパターンが有効的な手段になります。
具体的な利用例としては、共通変数の管理や滅多に変更されないコードと名称の組み合わせを持っておく等が考えられると思います。

私はJavaでデザインパターンを覚えたこともあって、インスタンス取得のために GetInstance のようなメソッドを用意したいたのですが、もっと画期的な方法がありましたので紹介したいと思います。
C# でのシングルトンの実装
画期的と言っても、実装方法はほとんど変わらず、プロパティを利用しただけなのですが、コードはとてもすっきり見やすくなっています。
応用例としてマルチスレッド対応のシングルトンや静的な初期化も説明が載っています。

【ASP.NET】JavaScriptとコードビハインド

  • Posted by:
  • 2006年7月11日 22:25

ASP.NETの画面を見ていると、当然のごとくJavaScriptが出てくる。
よくよく考えてみると、JavaScriptはエンジニアに嫌われる代表的な技術だと思う。
ブラウザ依存するし、デバッグは面倒くさい。
作り方によってはセキュリティに影響を与えることもある。
しかも、ブラウザの設定でオフに出来ちゃう。
でも、応答速度を求められると、これを使わざるを得ないのが現状なんですよね。

あと、とっても気になる点として、コードとビューの分離「コードビハインド」に関わる問題があります。
ASP.NETでは、JavaScriptで処理していたコードをイベント記述することで、コードとビューを分割できることを売りの一つとしています。
要は、「画面は画面、ロジックはロジック」とハッキリさせた方が分かりやすいし、メンテナンスしやすいでしょ?ってことなんだと理解してます。
従って、いくら入力チェックとはいえ、HTML(ASPやJSPも含む)上にロジックを書くってのは、ちょっと違うんじゃないかなあと思うわけです。

しかしながら、現実的に目の前に広がる世界にはJavaScriptが溢れているわけで、急に無くすと政治的な問題になりかねないので、思案のしどころです。
とりあえずの策として、WEBコントロールのAttributeにJavaScriptを突っ込む方法でいこうかと考えていますが、普通はどうやるんでしょうね???

謎は深まるばかり。

System.Data.Common名前空間

  • Posted by:
  • 2006年7月 7日 00:24

System.Data.Common 名前空間
ADO.NET でのプロバイダに依存しないコードの作成

これすごいです。
7/4の記事でポリモーフィズムがどうたらとか書いていたんですが、もうどうでもいいです(泣)
VisualStudio.NET 2003までは、各プロバイダ用にサブクラス化していた(さらに言うと、依存DLLの関係でプロジェクトも分けていた)んですが、もうそんな必要は無いようです。

で、早速使ってみました。
たとえば、SqlParameterなんかの場合はDbParameterなんて感じになります。
基本的にDb****という命名になるようですね。
Newする際には、ファクトリクラスを使ってCreateするだけのお手軽さでした。
デバッグ実行でブレークしたついでに、オブジェクトの状態を見てみると、ちゃんとプロバイダごとのオブジェクトが生成されてます!
速度も特に遅いと感じたこともなかったので、今後はこれがスタンダードになるのかな。

【VisualStudio】出力ウインドウへメッセージを表示させる

  • Posted by:
  • 2006年7月 4日 14:59

テスト用にVisualStudioの出力ウインドウにメッセージを表示させたいとき、System.Diagnostics.Debug、System.Diagnostics.TraceのWriteメソッドを使用します。

両者の違いは、それぞれDEBUGディレクティブ、TRACEディレクティブが宣言されているかどうかです。
この宣言はVisualStudio2005の場合、プロジェクトのプロパティでチェックするだけで宣言したことになります。

[HOWTO] Visual C# .NET でのトレースとデバッグの方法

O/Rマッピング

  • Posted by:
  • 2006年7月 4日 12:24

O/Rマッピングを調査中です。
というか、激しく悩んでいます。

O/Rマッピングを簡単に説明すると、オブジェクトとリレーショナルデータベースを自動的にマッピングする仕組みです(簡単すぎ:汗)。
Hibernateなんかが有名なんですが、SQL文、データベース名とオブジェクト名のマッピング、テーブルのカラムとクラスのフィールドのマッピング等をXMLに定義しておくことで、自動的に変換してくれる仕組みです。

これを導入することで、オブジェクト指向とリレーショナルデータベースの思想の違い(インピーダンスミスマッチ)を解決できるし、ビジネスロジックにSQLが紛れ込むこともなくなります。
また、SQLがXMLに書かれるため、メンテナンスがし易いといったメリットもあるのです。

当然のことながら、C#でも実装できますし、オープンソースでもいくつかあります。
ところが、.NETではDataSetというのがあって、これを使うことでデータグリッド等の表示が簡単に行えるので、わざわざエンティティクラスを定義する必要があるのか微妙なところです。
というか、DataSetをエンティティクラスの代わりに使うこともできちゃいますし。(現実世界の構造とは狂うかもしれないが)
あと、DataTableを変更したときに、変更内容に応じて自動的にInsert、Update、Deleteを行ってくれる機能まであったりする。
しかも、Abstractクラスでメソッド宣言するときに、パラメータなんかとインタフェースで定義しておいて、実装はサブクラスで行うようにすれば、ADO.NETだけでなく、ODP.NETやpgsqlでも、ポリモーフィズムが実現できる。

また、SQLをXMLに書くというのも、私は大歓迎ですが、O/Rマッピングを知らないエンジニアがすんなり受け入れてくれるとも思えないんですよねえ。
とりあえず、
・SQLをXMLに書かないが、データベース層に該当するクラス内に閉じ込める
・DataSetを返す
・機能(SELECT、INSERT、UPDATE、DELETE)と実装(SQLの実行、トランザクション処理、コネクション管理)を分ける
といったあたりを念頭にコーディングしてみることとする。

C#とVB.NETとの違い(その2)

  • Posted by:
  • 2006年6月29日 22:55

構成ファイル(Web.config、App.config)の値を読み込む際に
[VB.NET - .NET2003]
myConfig = (NameValueCollection)ConfigurationSettings.AppSettings(strAddress);
myConfig = (NameValueCollection)ConfigurationSettings.GetConfig(strAddress);

こんな風に書いていた訳だが、そのままC#にコンバートしたらWarningが出た(泣)
警告'System.Configuration.ConfigurationSettings.AppSettings' は古い形式です: 'This method is obsolete, it has been replaced by System.Configuration!System.Configuration.ConfigurationManager.AppSettings'
Warningなので放置プレイでも良かったんだけど、そこはエンジニアとしてのプライドが...

[C# - VS2005]
myConfig = ConfigurationManager.AppSettings[strAddress];
myConfig = ConfigurationManager.GetSection[strAddress];

単純にConfigurationManagerに置き換えるだけかと思いきや、MSDNを見るとSystem.Configurationを参照に追加しないといけないみたい。
あと、GetConfigはGetSectionに。
usingはそのままでいいのに、変なの~

C#とVB.NETとの違い(その1)

  • Posted by:
  • 2006年6月29日 22:48

今月から仕事の関係でC#を勉強中。
と言っても、いきなりフレームワークの作成なんかしてたりする。

以前VB.NETをやっていたので、文法の置き換えだけですぐなじめると思っていたのだが甘かった...
C#に比べると、VB.NETは規則が緩いのである意味何でもできたりする。
逆にC#はいろいろな部分が厳密なため、品質の高いコードが書けそうな気がする。

また、今使っているのがVisualStudio2005なので、新たな機能も当然の事ながら追加されている。
この辺りも備忘録として残していくつもり。

Index of all entries

Home > プログラミング > C#.NET Archive

Search
Feeds
Tag Cloud
Recommend

SQLパズル 第2版 プログラミングが変わる書き方/考え方
SQLパズル 第2版 プログラミングが変わる書き方/考え方

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

ITアーキテクト vol.1
ITアーキテクト vol.1

オブジェクト指向における再利用のためのデザインパターン
オブジェクト指向における再利用のためのデザインパターン

増補改訂版 Java言語で学ぶデザインパターン入門
増補改訂版 Java言語で学ぶデザインパターン入門

増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編
増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

J2EEデザインパターン
J2EEデザインパターン

アンチパターン―ソフトウェア危篤患者の救出
アンチパターン―ソフトウェア危篤患者の救出

世界でいちばん簡単なネットワークのe本―ネットワークとTCP/IPの基本と考え方がわかる本
世界でいちばん簡単なネットワークのe本―ネットワークとTCP/IPの基本と考え方がわかる本

Return to page top