C# でイベントハンドラにイベントが登録されているかどうかを判定するために
Nullチェックするのが定石のようですが、
以下のサイトで、空デリゲートを最初に登録するという方法が紹介されています。
イベントに空デリゲートを仕込ませてみる
public event Action<object> SampleEvent;
と定義して、どこかのメソッド内で
if (SampleEvent != null) {
//処理
SampleEvent();
}
が
public event Action<object> SampleEvent = delegate {};
と定義と初期化して、どこかのメソッド内で
//処理
SampleEvent();
となります。
このサイトでもメリット・デメリットの議論がありますが、
Nullチェック忘れの予防のために、masoojerにはこちらを採用したいと思います。
2013年11月9日
2013年5月15日
Visual Studio Express 2012 for Windows Desktop でデータベースのマイグレーション
基盤ライブラリが固まらない
Entity Framework は、使いやすそうでとても素晴らしいのです。しかし、Express エディションからの使用制限が厳しいので、今回の案件では使用せず、別の ORM・マイグレーションツールを導入する事にしました。
いろいろ探し検討した結果、表題にあるマイグレーションツールについて今回開発に導入する事にしたのは、
- fluentmigrator https://github.com/schambers/fluentmigrator
です。
NuGetパッケージがあるのと、使用ユーザーが多そうだからというのが、決定の理由です。
導入は、別プロジェクトとして
本体のプロジェクトに導入すると、不要なものが実行ファイルに含まれてしまうので、クラスライブラリのプロジェクトを新たに作成しました。新たに作成したプロジェクトに NuGet パッケージFlunt Migrator, Flunt Migrator Tools を導入します。
参照設定は自分で
使用するデータベースによって設定するDLL が違うようです。今回の開発では、MySQLを使用するので、参照設定に Flunt Migrator Tools でインストールしたパッケージのディレクトリにある Mysql.Data.dll を追加します。
さらに、 MSbuildで実行するので、FluentMigrator.MSBuild.dll も参照設定を行います。
マイグレーション方法
マイグレーションを実行するファイルはhttps://github.com/schambers/fluentmigrator/wiki/Migration-Runners#msbuild-runner
で手に入るものを修正しましょう。
私は以下のようにしました。
vi migrations.msbuildproj
<?xml version="1.0"?> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Migrate"> <UsingTask TaskName="FluentMigrator.MSBuild.Migrate" AssemblyFile="bin/build/FluentMigrator.MSBuild.dll"/> <Target Name="Migrate" > <Message Text="Starting FluentMigrator Migration"/> <Migrate Database="mysql" Connection="Server=サーバIPアドレス;Port=3306;Database=データベース名;User Id=ユーザ名;Password=パスワード;" Target="bin/build/project_migrations.dll"> </Migrate> </Target> <Target Name="MigrateRollback" > <Message Text="Starting FluentMigrator Migration Rollback"/> <Migrate Database="mysql" Connection="Server=サーバIPアドレス;Port=3306;Database=データベース名;User Id=ユーザ名;Password=パスワード;" Target="bin/build/project_migrations.dll" Task="rollback"> </Migrate> </Target> <Target Name="MigrateRollbackAll" >> <Message Text="Starting FluentMigrator Migration Rollback All"/> <Migrate Database="mysql" Connection="Server=サーバIPアドレス;Port=3306;Database=データベース名;User Id=ユーザ名;Password=パスワード;" Target="build/project_migrations.dll" Task="rollback:all"> </Migrate> </Target> </Project>
自動化はできていない
自動化は、まだできていなくて、VS2012の開発コマンドプロンプトから
MSBuild migrations.msbuildproj
で実行しています。
2013年1月26日
C#のDisposeメソッドの意義
はてブの整理を行っていた時に掘り起こしました。
@ITの掲示板で、以下の質問がありました。
「Dispose の意味が未だわからないのですが」
質問の概要は、なんで finally で Dispose の呼び出しを保証しないといけないのか?
という事なのですが、当時いろいろなC#の入門サイトを見ていた私も不思議でした。
今改めて考えてみると、
「Dispose の呼び出しを必ずしないといけない」と規則のように考えるから混乱するのであって、
Disposeメソッドがあるようなクラスは、ほぼ何かのリソースを確保していて、
それを開放しないと、リークしてしまいます。
try してリークしたくなかったら finally にちゃんとDispose書いとかないと抜け道ができるよ。
リソース開放されないの気持ち悪いでしょ。何かのバグになるかもよ。
だからfinallyにつけとこうよ。
という事なんだと理解しています。
しかし、C#には usingステートメントという便利なものがあるのだから、そもそもこの議論は無意味なんですよね。
@ITの掲示板で、以下の質問がありました。
「Dispose の意味が未だわからないのですが」
質問の概要は、なんで finally で Dispose の呼び出しを保証しないといけないのか?
という事なのですが、当時いろいろなC#の入門サイトを見ていた私も不思議でした。
今改めて考えてみると、
「Dispose の呼び出しを必ずしないといけない」と規則のように考えるから混乱するのであって、
Disposeメソッドがあるようなクラスは、ほぼ何かのリソースを確保していて、
それを開放しないと、リークしてしまいます。
try してリークしたくなかったら finally にちゃんとDispose書いとかないと抜け道ができるよ。
リソース開放されないの気持ち悪いでしょ。何かのバグになるかもよ。
だからfinallyにつけとこうよ。
という事なんだと理解しています。
しかし、C#には usingステートメントという便利なものがあるのだから、そもそもこの議論は無意味なんですよね。
登録:
投稿 (Atom)