Silverlightとインターフェイスの話

どうもJudaです。
XAMLの技術とInterfaceの親和性についての話。
XAMLで記述して、事前にデータバインディングのターゲットを固定させて、そこへのアクセスを確率できるようなInterfaceを公開することは有益なのだろうかと言う問から端を発しました。
試作段階に置いてXAMLで表示したいものと表示の形式がある程度固まると、そのバックエンドとなる部分で調整になると思います。その時に、もっとも合致する機能はInterfaceではないのかという思いつきですが、そこそこ有益だと思います。
Interfaceなら実装を保証させるので、それによってバインディングエラーを減らすことができます。ここで注意したいのは、XAMLのほうでTwoWayを採用するなら、Interfaceに必ずSetterを書いておく方が混乱が少ないのですが、それ以外のOneTime、OneWayの場合には、それはInterfaceで規約するのではなく、実装側の裁量に任せる方がいいとおもう。また、OneWay、TwoWayの場合にはINotifyPropertyChangedの継承が実装側で最終的に必要になるので、それも検討しておきたい。
別の話にはなるが、INotifyPropertyChangedでプロパティの変更を検知する処理を組み込んで、Setterなりを修正するのだけれども、この場合には、自作でSnippet、もしくはマクロを組むことが有効であると思う。大半のコードが同一になるので、これをおすすめしたい。しかしながら、簡易でPropertyを書いた場合、つまり　get;set;のプロパティへの変更検知機能の追加はめんどくさい。なんとかならないのかと思っている。
話は戻るが、Interfaceの基本的な考え方とXAMLでのバインディングの記述の間にある程度の親和性があり、これを再利用出来る形で提供すると面白いのではないかと思う。しかしこれでは何が問題になるってくるのか、まではまだちゃんと確認出来ていない。Interfaceがそういう具体性を求めているのではないとすれば、この考え方はあまり良くないと思うが、個別の開発でフロントエンドとバックエンドを分離して開発するときには、いちいち名称の確認をとらなくてもよくなって、個人的にはいいと考えた。

DataServiceKeyAttribute("ID")

どうもJudaです。

Reference.cs

[global::System.Data.Services.Common.DataServiceKeyAttribute("ID")]

こいつか。。。

昔おいらを苦しめたのは。。。。

追記；

あれ、違う。。。

Silverlight Content Controlについて

どうもJudaです。

いっこ前の話

なんとなくですけど、Contentって名前は既に使われているので、これをそのまましようすることはできないので、DependencyPropertyでObjectで任意のコントロールを生成する。そしてPropertyのSetterで登録を行えば、なんとか認識して使用できますが、明確に登録するプロパティを使用しないイケないので、ちょいと見栄えが悪くなります。ここらへんはどうすればいいのかわからない。

SilverlightにおけるCustom Content Control

どうもJudaです。

Silverlight Custom Content Control

まさに掲題のとおり、Contentを表示したい時があります。

けれども簡単に行う方法はよくよく調べないとわかりません。Custom Template Bindingもひとつの手ですが、それもそれでなかなか大変なのです。（本当か？

Silverlight 2 のカスタム コントロールを作成する

うん、なんかいろいろめんどくさい。