ラベル .NETFramework の投稿を表示しています。 すべての投稿を表示
ラベル .NETFramework の投稿を表示しています。 すべての投稿を表示

5/23/2010

Webサービスのリファレンスの追加に関して。

どうもJudaです。
Webサービスのリファレンスの追加に関して(VS2008)。
Webサービスの追加を行うと、こっそりReferenceファイルが生成されますが、定義から飛ばないと生成されたものを確認できません。定義を確認するとわかるのですが、クラスがpartialで定義されています。これが何を意味するのかと言うと、自動生成のファイルのバックエンドへ変更点を書き込むと更新時に修正、変更した部分を破棄されてしまうので、別ファイルで定義を明確に書いてねって事みたいです。
例えば、EntityのEntityDataという名前のクラスが取得される場合に、その中の要素はPropertyとして生成されます。これに対して、INotifyPropertyChangedを実装しようとします。しかしそれをReferenceに書いてしまうと、更新時に破棄されますので、別ファイルに名前空間に整合性を持たせつつ、PartialなEntityDataを定義します。あとはPartialのキーワードを利用して、各項目のOnChangedやOnChanging(object value)を定義してやれば、独立してプロパティの変更前と変更後の処理を定義出来ます。これでINotifyPropertyChangedを実装可能になります。

3/27/2010

ADO.NET Data Serviceにおける注意点

どうもJudaです。

ADO.NET Data Serviceの暗黙的な制約があるっぽいので、注意を。

このサービスを作るときに.svc.csファイルに記述をしていくと思いますが、この時に注意があります。基礎となるデータ構造へのアクセスを提供するIQueryableのプロパティを持つクラスはすべて一箇所にDataServiceと同じところに書いておかないとサービスが使えない。どうもそうらしい。もう少し厳密に調べてみる。それにしてもややこしいなぁ、このシステム。どうも最近VisualStudioのWizardが生成するコードとの相性が悪い。どうも道から離れているみたい。

追記

どうも原因が一定しないみたい。問題を捉えたと思ったら逃げられた。一箇所にデータを入れておいたのに、サービスが認識されない。要求エラーが表示されて、内部にエラーが潜在してしまう。作り方自体は、各種サンプルを参考にしているがどうしても問題点を捉え損なう。

バイナリ化しているものの参照がうまく行っていない気もするけれど、いかにしてそれを捕まえるのか分からない。最近こんなんばっか。はしごが外されている。


もいっちょ追記。

DataServiceのTが扱っているEntityにNullにならない一意なIDになるものプロパティがないと、駄目だ。これがないだけで、全てがおじゃんになる。あとはEnumの継承型をEntityに含めることはできない。使えないんだよ。だから、大抵はint,stringのオンパレード。ちなみにDateTimeも使えない。これが痛い。使えるのかも知れないけど、とりあえず直接は入れられない。とりあえずこうすれば、コードを分割して記述してもいけるし、DLLで参照もできる。これもEntityをDBから作らないから、エラー出力をする属性も分からないし、調べ方も分からない。

3/17/2010

Silverlightとの戦い

どうもJudaです。
Silverlightと最近は格闘中ですが、面白いです。TemplateやBindingはパワフルで使い出のあるアドバンテージです。これらの機能を使いこなすことでコーディング量を劇的に減らすこともできますし、自分の中のデータとビューの関係性を捉え直す機会もくれます。実に取り組みがいのある技術です。この先には、まだまだ多くの発展技術がいることを考えると、挫けそうですが。
それはそうとSilverlight4RCがきましたが、まだ確認をしていません。それよりなによりVerUpの頻度が多い気がします。それ自体は悪いことではないですが、技術書が出揃わないうちにVerUpされると出版側が手を出しにくくなって、困ります。ただでさえ、少ないのに。
ブログなどもいくつも見ていますが、重要なのは基本的な機能に十分習熟することと、Bindingをコード側からも理解することがかなり重要ですね。特にとっつきづらいのはCanvasとGridの実際的な制約事項。
Canvasは自由配置できるのですが、Grid内に配置しても自由に配置を出来ること。Gridのみの場合には、自由配置が全くできないので、XAML側での構造の構築には気を使わなければなりません。あとはDrag&Drop機能を使おうと思うときには、構造をよくよく見れば明白ですが、ListBotのListBoxItemはListBoxの外ではそのまま使えないので、取り出したあとなんらかのコンテナを必要とする点や、データ自体の受け渡しのみならば、別のItemSoruceをもつものとも融通がきくことなど。
実際にコードを触らないとあまりに些末で考えなければならないことが多いです。

1/23/2010

WPFって?

どうもJudaです。

今さらですが、
Windows® Presentation Foundation - Microsoft
Windows Presentation Foundation - Wiki
まぁSliverLightの基礎的なフレームワークなんですけど、
これは既存のWindowsのFrameworkから脱却する目的で開発されているので、MFCとは違いますし、.net Frameworkとも違います。まぁ.netとはとても近いですけどね。
重要なのはこれがまぁ新しいフレームワークで、なおかつDesktopとWebをそれほど区別しない点、UIとLogicの分離をフレームワーク的に強制するところです。

これによってMVCのような粗な結合を作ることが推奨されますし、これによってOOP、テストの導入などがしやすくなると考えられます。しかしこれは、ある程度以上の興味と技術をもっていないと上手くいかないので、学習コストをそれなりに払う必要があると思います。
もっとも悲しい事例をあげるなら、すべてが無理やり結合されている。もしくはそれに近い状態におかれることでしょう。例えるなら果物ナイフで巨木を切り倒すようなことにならないように、適宜道具の吟味とその使用法を確認する必要があります。
WPFはC#とVBから利用できる点も特筆しておきたいです。

12/23/2009

理由はわかっているけれど、やってしまう間違い

どうもJudaです。
今日はXMLシリアライズな話


using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Serialization;
using System.IO;
using System.Xml.Serialization;

namespace SerializeDaemon
{
class Program
{
static void Main(string[] args)
{
XmlSerializer xmlSel = new XmlSerializer(typeof(Deamon));
StringWriter wStrm = new StringWriter();
Deamon hoge = new Deamon();
xmlSel.Serialize(wStrm, hoge);
Console.WriteLine(wStrm.ToString());
}
}
public class TestA : ISerializable
{
protected int m_id = 0;
public TestA() { }
public int Id
{
get { return m_id; }
set { m_id = value; }
}

#region ISerializable
protected TestA(SerializationInfo info, StreamingContext context)
{
m_id = info.GetInt32("Id");
}
public void GetObjectData(SerializationInfo info, StreamingContext context)
{
info.AddValue("ID", m_id);
}

#endregion
}
public class TestB : TestA
{
public TestB() : base() { }
protected TestB(SerializationInfo info, StreamingContext context) : base(info, context) { }
}
public class TestC : TestA
{
public TestC() : base() { }
protected TestC(SerializationInfo info, StreamingContext context) : base(info, context) { }
}
public class Deamon : ISerializable
{
TestA m_id0;
public TestA Id0
{
get { return m_id0; }
set { m_id0 = value; }
}

TestA m_id1;
public TestA Id1
{
get { return m_id1; }
set { m_id1 = value; }
}

TestA m_id2;
public TestA Id2
{
get { return m_id2; }
set { m_id2 = value; }
}

public Deamon()
{
m_id0 = new TestA();
m_id0.Id = 100;
m_id1 = new TestB();
m_id1.Id = 4000;
m_id2 = new TestC();
m_id2.Id = 6000;
}
protected Deamon(SerializationInfo info, StreamingContext context)
{
m_id0 = (TestA)info.GetValue("ID0", typeof(TestA));
m_id1 = (TestA)info.GetValue("ID1", typeof(TestA));
m_id2 = (TestA)info.GetValue("ID2", typeof(TestA));
}

#region ISerializable

public void GetObjectData(SerializationInfo info, StreamingContext context)
{
info.AddValue("ID0", m_id0);
info.AddValue("ID1", m_id1);
info.AddValue("ID2", m_id2);
}

#endregion
}
}

コンパイルは通るけれども、実行はできないソースコード。
問題点は、シリアライズ対象のクラスがもっている要素に継承クラスが代入されていること。これはシリアライズにおいて、とても大変な問題をはらんでいる。
サブクラスをシリアライズする方法なんてわからないのだから。
シリアライズという行為が現状を復元可能な形で保存することにあるときに、継承クラスかどうかの判定なんて誰がどうやってするんだろーって事で原理的に今は無理です。柔軟に対応しないといけないならば、むしろ別の方法でそれを実現する方法を探す方が賢いと思います。あるいはできるなら、それを教えてください。
とりあえずは素直にすべての要素が構造体で定義されているものをシリアライズするコンテナクラスとして使用しましょう。というお話です。

細かな点ですが、インターフェイスはコンストラクタを規定できないので、実はISerializableの実装はちゃんとコンストラクタを特別に作っておかないとダメです。
ややこしいですねー。

12/10/2009

ControlController

どうもJudaです。
.net Frameworkをつかって、フォームをデザインするときにでるあの特別なコントローラーが気になります。
あれがとってもほしいのです。
考えられる方法は幾つかありますが、C#,VBがOOPと言えども、言語的にクラスの継承の間に割り込みはできないので、委譲のほうで問題を回避していくことが重要かもー。
コントロールを入れられるコントロール制御用のコンテナを用意して、そのコンテナに対して制御を加えるようにすれば、汎用的にコントロールを扱えますね。うん、というか、それ以外に思いつきません。
調べたところ、既にこのコントローラを開発した人もいるのですが、2003で作られているし、またこれに限っては車輪の再発明も幾分か自己のOOPへの理解や修練に役立つので少し試行してみる。

取り替えずコンテナをクラスで宣言します。描画の関係もあるので、Controlを継承した方が無難なので、継承する。ただここで考えるのは、
・これにコントロールを入れて、
・Mouse系のイベントを使うこと、
・Key系のイベントでの制御も許容すること。
・同時に周りのコントロールとの数値の関係性によって拘束がかかること。
・選択時には特別な描画処理を行うので、Paintイベントも書くこと。
意外と使い易いコンテナをつくるには問題がありそうだ。
コントロールをコンテナに格納したときに、格納したクラスの個別のマウスやキーのイベントをハックしないといけないので、これが若干気になりますねー。コンテナ格納後に個別のコントロールのイベントが生きていると困るので、殺しておきたいのですが、よくわからないのであとで調べておきますね。
たぶん内側を透明にしてZバッファの順序を入れ替える。もしくはフォーカスイベントが発生するとフォーカスを移すとかですけど、フォーカスのイベント内でフォーカスを移動させると予想外の動きをするので、あまりおすすめできません。以前、実験した際に、呼び出しが規則的に発生しないことを確認したので、フォーカスを制御するのは、確実性に疑問があるので、別の方法を模索するほうがいいです。
あとはコントロールが登録されているものを入れ替えてしまうかですが、これはデータの構造を勝手に書き換えることになるので、おすすめできません。汎用性にかけることは間違いないので、なるべく同一の階層性でイベントの登録のみで解決したいですね。
…別にコンテナを開発しなくても、イベントの登録、削除をうまく制御すれば、データ構造的な面では出来そうですが、すでに存在しているイベントとぶつかったり、そもそももとのイベントが駆動してしまう問題があるので、これはうまくいきそうにないです。
ここまでの問題点で一番大きいのは、コントロールに発生するイベントを一時的に殺して、それをバイパスして別のコントールに移すことができるのかどうかです。そのあとは、ここの機能を分割しながら実装していけば問題はなし。
初回ではなく、選択後つまりコンテナに入れられた後に、そのあとは独占的にコントロールを支配できなければいけません。なにか方法はないものでしょうか?

5/31/2009

.NET Frameworkにおける列挙型の中身の列挙

たとえば、列挙型の中身をComboBoxに列挙してみたいとする。
ではどうするか、全ての列挙子を並べて追加するのか?
それが賢いと思えるのは、中身が3つぐらいまでだ。
ではどうするのか。
コレに関しては名前と値とどちらがUniqueなのかが重要である。
ユニークなほうをキーとして使う。
System.Enumのクラスメソッドを使用すれば、綺麗に作れる。
enumはEnumを継承しているように扱われるので、これが最善である。
あとはそこにあるメソッドをつかって好きなように。
ただし、復元するときにはParseを使う。ただ、こいつにはTryParseがないので、例外処理に関しては失敗しにくいとはいえ、可能性は0ではないので、気をつかうべし。

5/20/2009

デフォルトコンストラクタ

なんだか、VBにも慣れてきましたが、私はC#スキーです。

VisualStudioでWindowsFormApplicationをつくっている人で、困ったことにならないように事前に注意。Formから派生したものでDesignerをつかってレイアウトなどをいじる人は、絶対にデフォルトコンストラクタ以外のコンストラクタを作らないこと。
引数なしの単純なコンストラクタ以外を作ると一発で駄目ですっていわれます。
コマンドライン引数がほしいときは、Application名前空間のものを使えばいいと思います。
それ以外にもLoadイベントの中でエラーが起きると、Designerが死にます。UserControlもオブジェクトファイルなりDLLなりがないと不安定になります。

VBは基本的には型指定なしでガンガンコードを組むための言語なのですが、なぜかデリゲートに関してはナイーブです。匿名メソッドへの対応がなかったり、NULL参照がしにくかったり、意外とFrameworkとは相性が悪かったりします。クラスメソッドをインスタンスから使えたりするので、これは非常にややこしいです。暗黙的に引数に指定してくれると楽なのですが、そうもいかないのでなんだかなぁです。

話は変わりますが、UserControlはただ作るのでは、まったく使えません。かといって、全てのコントロールをAccess可能にして使うのも下策だと思います。確かに扱いやすいのですが、それでは結局はただ配置しただけで、むしろ複雑な操作を要求するようになるだけでいまいちです。カプセル化やインターフェイス、イベントドリブンの組み方を少しは理解しておいてからおこなうと、すっきりとしたものが作れます。またこれに付随して属性の勉強を始めるとできることが目に見えて増えるので、この経路での属性の学習はありだと思います。
ただ、このUserControlはVSとの親和性が異常に低いので、いろいろなところでエラーやミステイクの温床になるので、気合を入れて使ってください。ただ、これは慣れると、構造がすっきりして見易く、カプセル化や抽象度の変化についての考えが深まるので、使えなくなると逆に不満が爆発するでしょう。
でもマジUserControlでよく使うコントロールや巨大なコントロールをクラスにすると扱いが簡単になって幸せです。オブジェクトのネストが5とかになると管理がしにくいので、一考の余地アリです。

3/31/2009

日々、吾ハ習ヒ試シ違ヒ試スナリ: .NET Framework のDictionaryの弱点

日々、吾ハ習ヒ試シ違ヒ試スナリ: .NET Framework のDictionaryの弱点

この記事の話ですが、
よくよく調べるとDictionaryEntryの配列が存在しました。
こいつは、PropertyがKey,ValueともにGetSetなので、
期待しているSerializeの働きを行うのに適合します。
これによってデータがSerialize、Deserializeされることが
確認できましたので、覚書ですが、ここに記します。

3/04/2009

.NET Framework のDictionaryの弱点

Dictionaryの弱点というか、クラスの設計上の弱点という盲点だと思うけど。

Serializeすることができない。

答えは復元することができないからだ。

KeyValuePairでのKey、ValueのそれぞれはGetしかできないので、その後の復元ができないのだ。しかし辞書クラスは外部にデータを取り出したい、ときもある。
しかもややこしいことに大体この一対一のペアになるようなデータ構造のものは結構あるという罠。
かといって、このために新たに構造体を作るのもなにか負けた気がする。

解決策は...わかりません。
さらに問題なのは、IFormatConverterとかいうSerializeのための変換インタフェイスがあるのですが、実装しなおさなければならないということ。GenericClassなんだから最初から実装してよ、って思いました。

PS. 
もうどうしようもないので、拡張してしまった先の話
PS.2
このようなTopicに関する議論。ところどころ
冗長だと思うけど。