はてなブックマーク

今年はASP.NET MVCを利用したアプリケーション開発に携わったのでその感想をまとめます。 軽量・小回りが利く ASP.NET WebFormに比べて出力するHTMLを全てコントロール可能でシンプルなHTMLを出力することができます。このためCSSやJavaScript（jQuery）の利用も直観的で相性も良いです。 WebFormに比べ欠点としてはVSデザイナによる画面作成ができない点がありますが、実行すれば画面確認できるので、微調整はHTML修正保存・ブラウザ更新のサイクルで行えばそれほど苦になりません。またテーブル形式にタグを配置したり用のレイアウトを支援するヘルパーを作成するなどの工夫をすることができます。今回、タブレットとPC両方がターゲットでリキッドレイアウトが基本なのでこの仕組みは役に立ちました。 HTMLメッセージパターン 今回ほぼ全てのリクエストをajaxで行います。

最近BRMSという言葉とよく聞くようになりました。言葉だけは以前から知っていいて昔のエキスパートシステムの派生版のように思っていました。しかし、現在はより広範囲に、（少し違和感を感じますが）プログラムの自動生成的なものにもBRMSという言葉を使うケースもあるようです。 今回は前者のエキスパートシステムで利用されるIF−THEN型ルール実行エンジンを.NET環境でお手軽に導入できるので紹介します、 WF（Windows Workflow Foundation）ビジネスエンジン ビジネスルールを実行するためのエンジンは実は.NET FrameworkのWFに以前から用意されています。どのような機能があるかはWindows Workflow Foundation ルール エンジンの紹介を参考にしてもらえば分かると思いますが、このルールエンジンはワークフローデザイナで利用するのが一般的なのですが、

簡単にできるかなと思って手をつけたのですが案外大変です。 最初のDataGrid まずは出発点となるDataGridですが以下のような３つの列を持つものです。 ヘッダーを2段にする ヘッダーを2段にする方法をまず検索したところいくつかアイデアが見つかりました。大まかに分けてDataGridのDataGridColumnHeaderのレイアウトと変える方法とDataGridの上部にGridを配置する方法です。どちらも試した見たのですが、後者の方がColumnSpanがし易そうなので採用しました。 WPF multi-column super headerを参考にコードを追加しました。 Elementバインドを利用してDataGridのリサイズにも対応できています。しかし問題があります。まず横スクロールに対応していません。また上部ヘッダーでカラムのリサイズ機能が利用ができないです。順番に対処を

volatile 修飾子 C#にはvolatileという修飾子がある。MSDNのC# リファレンスでは以下のように説明している。 volatile キーワードは、同時に実行中の複数のスレッドによってフィールドが変更される可能性があることを示します。 volatile と宣言されているフィールドは、シングル スレッドによるアクセスを前提とする、コンパイラの最適化の対象にはなりません。このため、フィールドには常に最新の値が含まれます。 volatile 修飾子は、通常、アクセスをシリアル化する lock ステートメント (C# リファレンス) ステートメントが使用されない場合に複数のスレッドによりアクセスされるフィールドに対して使用します。 まず、前半部分は他のスレッドより変更される可能性があるフィールドに対して最適化を禁止するためのもの、これはまあまあ想像できる。以下のようなコードでコンパイ

今.NETで業務アプリを作成するのであればRIAService＋Silverlightを使うことを勧めするだろうな。理由は高い生産性。 サーバー側の仕組みはEntity FrameworkとRIA Serviceで本当に簡単に作成できるし、クライアント側についてもRIA Serviceの呼び出しやエンティティを生成してくれる。しかも、アグリゲータやプレゼンテーションモデルの概念が組み込まれているので単なるテーブルのCRUDレベルではない機能についても十分実用的に利用できる点が素晴らしい。 RIAアプリが簡単に作れる どの程度の手間でアプリが作成できるか、AdventureWorksLTデータベースを使って以下のようなTreeViewをカテゴリを選択して製品一覧を表示し編集できる画面を作成したみた。 RIAServiceのプロジェクトを作成 まず最初にRIAServiceのプロジェクトを作成

SQL Serverに1億件を超える大量のテストデータを作成する必要がありできるだけ高速な方法を調べてみた。 ストプロを試してみる まずはストプロを作成してどの程度になる確認してみる。単純にループを回してINSERTを1件づつ行う方法でまずは100万件で試してみる。 ALTER PROCEDURE dbo.CreateData AS SET NOCOUNT ON DECLARE @RowCount INT SET @RowCount = 0 WHILE @RowCount < 1000000 BEGIN INSERT INTO TestTable VALUES (@RowCount, 'DATA' + right('0000000000' + convert(varchar, @RowCount), 10)) SET @RowCount = @RowCount + 1 END RETURN

フレームワークレベルでは丁寧なメモリリーク対策が必要と思いますが、アプリケーションレベルではメモリリークに対して神経質なコードを書かなくても良いと思っています。 ライフサイクルの長いオブジェクトを識別し管理する メモリリークの定義もいろいろありますが、少しぐらいViewやViewModelのインスタンスが残る程度は問題にせず、継続的にメモリが増加するような場合について対策できていれば多くのアプリでは問題にならないのではないでしょうか？ ようは、MVVMのViewやViewModel、Modelのライフサイクルがそれほど長くないのであればお互いが参照していても問題が発生しないという考え方で、あとは、ライフサイクルの長いオブジェクトを識別して適切に管理するという、一般的なメモリリーク対策に落とし込むアイデアです。 MVVMの長いライフサイクルをもつオブジェクトとしては、Viewであれば起動時の

MVVMをかなり使い込んで来たのでいろいろまとめたい内容があるのだがなかなか時間がとれない。 とりあえずポイントをメモ書きしておく 業務アプリでのMVVMでのメリットは テスト性の向上などはあるが、最大のメリットはテクノロジ非依存に画面ロジックを作成でき保守性・移植性が高くできる点を挙げておこう。 逆にデメリットは ViewとViewModelの分離など設計時の初期コストが高くてっとり早く作れない点だろう。 MVVMの設計ポイント 以下の３つの要素に分けて画面を整理する コマンド ユーザ操作に対する処理でViewModel上のデータや状態に対して影響を与える処理。ViewModel上のメソッドとして実装される。 データ ユーザが確認・入力する情報。ViewModel上で論理的に適切な構造で保持されプロパティとして実装される。Viewで適切な形式に変換して表示し、入力されたデータはViewM

これはいい。 Symbols in C# 3.0 http://themechanicalbride.blogspot.com/2007/03/symbols-on-steroids-in-c.html 以下のようにobjectクラスを拡張すると public static string GetPropSym<TObj, TProp>( this TObj @this, Expression<Func<TObj, TProp>> expression) { return ((MemberExpression)expression.Body).Member.Name; } ラムダ式を使ってプロパティをシンボルのように使える。タイプセーフになる。 public class Hoge { public string Name { get; set; } } class HogeTest { pu

１年に１回だけの記事ですが今年もふりかえりをします。 Keep ・自転車と水泳はずっと続いている。今年は念願の北海道に輪行ツーリングしてきた。留萌から羽幌・稚内、利尻島、旭川、富良野と周ってきた。楽しかった。来年も北海道には行きたい。 ・週休3.5。仕事量を減らしてもらった。1,2週間程度の休みも何度か取れらしてもらっていい感じで働くことができた。来年も続けることができるかはわからないが、可能であればこのペースは気に入ってるので続けたい ・ChatGPTの利用。去年のふりかえりにGPT-3をあげているけどLLMの進化の早さに驚いている。プログラミングやデータ分析などで使っているけど素晴らしい。AGIを予感させるというか個人的には今のレベルで汎用性が高くAGIと言ってもいいように感じる Less of ・FX。去年と逆でサヤ取りが封鎖されたので。ただ新しい方法を現在探索しているので復活はある

都合の良いシナリオでサンプルを作成するのではなく、既存のDBを使って実際に概念モデリングを行い、ドメイン駆動設計からドメインモデルにつなげて行きたいと思います。 ターゲットのデータベース AdventureWorksのテーブル定義はここにあります。並べるとこれだけです。それなりにあります。 Address ProductModelProductDescriptionCulture AddressType ProductPhoto AWBuildVersion ProductProductPhoto BillOfMaterials ProductReview Contact ProductSubcategory ContactCreditCard ProductVendor ContactType PurchaseOrderDetail CountryRegion PurchaseOrder

まだまだLINQについて調べたいことはたくさんあるが、とりあえず、いくつかのドメインモデルのパターンを作成したので振り返りまとめとします。 ORMとしてLINQ to SQL 一言でいってよくできたORMフレームワークです。 Expression TreeをSQLに変換するアイデアは、直前まで実行を遅延することができより的確なSQL文を発行できる点や、Expression TreeをQuery Objectとしてビジネスロジックで検索条件を記述でき・しかも型付きである点などは便利だと感じました。また、オブジェクト更新などのトラッキング機能や今回書きませんでしたがオブジェクトのキャッシュ機能など細かな点もよく考えられています。個人的には複数のテーブルにまたがるオブジェクトの読み出しや永続化のより細かな制御が行えるようにもう少し強化してもらいたい点はありますが汎用的なORMとしてはこのあたりが

普通はそんなの難しいからあきらめてもらうのだが、どうしてもやりたいというので考えることにした。 まずは、Googleで調べてみるとそれなりにHITする。みんな苦労しているんだな。 onbeforeunload 最初にたどり着いたのは、onbeforeunload イベントを利用する方法。onbeforeunload は ページがアンロードされる前に発生するものなので、リンクを押したりしたりするだけでも発生する。なので、クローズ以外でも発生することが問題になり、これを対策する必要がある。がんばってみよう。 よく利用されている対策は、onbeforeunloadイベントが発生した際の event.clientYやevent.clientXを調べて0より小さい場合はCloseだと判断する方法である。しかし、この方法だと更新ボタンを押してもCloseだと判断してしまう問題がある。 これを対策する方

Windows Formの検証機能は2.0で大幅に強化されそれなりに実用的になっている。 しかし、案外癖があって？？？状態になることも多い。 以前部分的に書いたことがあったのだが、利用上のポイントを簡単にまとめてみたい。 Validatingイベント 最初にWindows Formで検証を行うために用意された最も基本的な仕組みは各コントロールのValidatingイベントである。 Validatingイベントの処理では入力された値のチェックを行い、もしエラーがあればエラーメッセージを表示したりする処理を記述する。CancelEventArgsのCancelプロパティをtrueにするとそのコントロールにフォーカスを残すことができる。 private void textBox1_Validating(object sender, CancelEventArgs e) { int work; i

まずは、ナイーブなOO的な発想？で、全てのデータをメモリに読み込んでやる方法。これは基本的には難しいですよね。よっぽど少数のデータであればOKかも知れませんが。 次は、ドメインモデルでやらないで、その手前の処理（入力チェックなど）で行う方法が考えれますね。この方法はドメインモデルとして一意制約チェックをする方法にはならないので今回はNGですが、個人的にはこの方法はよく利用します。ドメインモデルをある程度理想的な条件が成り立っているモデルとすることで、複雑さを低減することができます。 では、どうするか？ チェックは検証ルールと考えればいいので、ドメインモデルでは対応する検証ルール用のクラスすなわち一意制約用の検証Specクラスを作成して利用するようになります。チェック方法は、Repository経由でチェックするIDのオブジェクトを読み出せるかどうかで簡単に判断できます。 public cl