Gushwell's C# Dev Notes

メールマガジン『C#プログラミングレッスン - LINQ to SQL編』で説明しきれなかった内容をブログに書いたものの目次です。
メールマガジンのバックナンバーも併せてどうぞ！

---

0.はじめに

1.コンパイル済みクエリ

2.DataContextのスコープ

3.接続文字列

4.DataContext.OnCreateって何？

5.読み込み専用でデータベースを利用する

6.データベースの作成

7.IDENTITY列の扱い

8.NULL許容の列を扱う

9.timestamp列とUpdateCheckプロパティ

10.ColumnAttribute.UpdateCheck プロパティ

11.独自メソッドを追加する

12.ADO.NETとの相互運用

13.エンティティクラスに検証を追加する

14.エンティティ クラスの更新時にデータを検証するには

15.挿入、更新、削除の動作のカスタマイズ

16.SelectWithUpdlock メソッドを自作

17.同時実行例外をいつスローさせるのか

18.競合時の処理

  

LINQ to SQLでは、ChangeConflictException の例外が発生した場合、その競合解決に、
DataContext.ChangeConflictsコレクションのResolveAllメソッドが利用できます。

そのコード例を示します。

try { db.SubmitChanges(ConflictMode.ContinueOnConflict); } catch (ChangeConflictException ex) { db.ChangeConflicts.ResolveAll(RefreshMode.KeepChanges); }
ResolveAllメソッドの引数の型であるRefreshModeには、
　KeepChanges、KeepCurrentValues、OverwriteCurrentValues
の３つの値があり、この値によりどのように競合を解決するのかを指定します。

KeepChanges
変更された値と変更前(他のユーザによって変更された)値をマージします。
両方で変更されていた場合は、当該クライアントの変更を優先します。

KeepCurrentValues
他のユーザによって変更された値は無視され、当該クライアントからの変更が有効になります。

OverwriteCurrentValues
当該クライアントによって変更された値は無視され、他ユーザによって変更された値が有効になります。

これを表で表すと以下のようになります。

	カラムA	カラムB	カラムC
1.User1,USer2が読み込んだ値	aaa	bbb	ccc
2.User1が更新	sss	ttt
3.User2が更新	xxx		yyy
結果:KeepChanges	xxx	ttt	yyy
結果:KeepCurrentValues	xxx	bbb	yyy
結果:OverwriteCurrentValues	sss	ttt	ccc

※ユーザ2で競合が発生し、ChangeConflicts.ResolveAllで競合解決を図った場合の例

競合の詳細な情報を取得したい場合は、DataContext.ChangeConflictsプロパティを参照します。
以下にそのサンプルコードを示します。

try { db.SubmitChanges(ConflictMode.ContinueOnConflict); } catch (ChangeConflictException ex) { foreach (ObjectChangeConflict cc in db.ChangeConflicts) { // 競合したエンティティオブジェクトを Categoryにキャスト // Categoryだけを変更したと仮定。 Category entityInConflict = (Category)cc.Object; Console.Write("Category ID: "); Console.WriteLine(entityInConflict.CategoryID); foreach (MemberChangeConflict mc in cc.MemberConflicts) { object currVal = mc.CurrentValue; object origVal = mc.OriginalValue; object databaseVal = mc.DatabaseValue; MemberInfo mi = mc.Member; // 競合したメンバー名(カラム名)を表示 Console.WriteLine("Member: {0}", mi.Name); // 書き換えようとしている値を表示 Console.WriteLine("current value: {0}", currVal); // 読み込んだときの値を表示 Console.WriteLine("original value: {0}", origVal); // データベースに書き込まれている値を表示 Console.WriteLine("database value: {0}", databaseVal); Console.ReadLine(); } } }

---

『LINQ to SQL番外編』は、今回を持って終了です。   

LINQ to SQLでは、楽観的同時実行制御の仕組みが組み込まれています。

たとえば、Customersテーブルの行のContactNameカラムをSubmitChangesメソッドで更新する場合、
LINQ to SQLは以下のような UPDATE文を発行します。

UPDATE [dbo].[Customers] SET [ContactName] = @p10 WHERE ([CustomerID] = @p0) AND ([CompanyName] = @p1) AND ([ContactName] = @p2) AND ([ContactTitle] = @p3) AND ([Address] = @p4) AND ([City] = @p5) AND ([Region] IS NULL) AND ([PostalCode] = @p6) AND ([Country] = @p7) AND ([Phone] = @p8) AND ([Fax] = @p9)
パラメータ p0, p1, p2... には、変更前の値が渡されます。
LINQ to SQL では、これによって他のユーザによって変更されていない場合にだけ、
このUPDATE文が成功することになります。
失敗した場合は、System.Data.Linq.ChangeConflictException例外が発生しますので、
他のユーザによる変更を把握できることになります。

SubmitChangesメソッドには引数を持つメソッドがオーバーロードされていて、
この例外が発生するタイミングを以下の２種類から指定できます。

1. 最初の失敗のときにのみ、例外をスローする

2. 失敗したすべての更新についての情報を収集してから、例外をスローする。

具体的な例外発生時の処理を指定したコードを示します。
// 最初の競合発生で例外を発生させ、更新を中止します。 db.SubmitChanges(ConflictMode.FailOnFirstConflict); // 同時実行の競合を累積し、処理終了時点で例外を発生させます。 db.SubmitChanges(ConflictMode.ContinueOnConflict);
競合発生した場合、どのような対応ができるのかは、次回説明します。

---

LINQ to SQL番外編とは
メールマガジン『C#プログラミングレッスン』で連載した「LINQ to SQL編」には書ききれなかった情報を
「番外編」としてブログにアップしています。
併せて、メールマガジン『C#プログラミングレッスン - Linq to SQL編』も読んでいただけると、
より理解が深まると思います。
バックナンバーは、メールマガジン『C#プログラミングレッスン』書庫のページからダウンロードできます。

  

LINQ to SQLでは、UPDLOCK付きの SQL文を発行させることができません。
以下のように書ければ良いのですが...
var customer = from c in db.Customers with updlock // エラー where c.CustomerID == "ANATR" select c; このような場合は、しかたないので、ExecuteQueryを使います。
using (var db = new NorthwindDataContext()) { string sqlstr = @"select * FROM [Customers] WITH (UPDLOCK) WHERE [CustomerID] = {0}"; var result = db.ExecuteQuery<Customer>(sqlstr, "ANATR"); } これで、UPDLOCK付きのSELECT文を発行できます。

ただ、こういったSQLは、ストアドプロシージャを使う方が良いかな、と個人的には思います。
このあたり、LINQ to SQLの経験豊富な方の意見を聞いてみたいものです。

しかし、いちいちSQL文を手書きするのはイヤですよね。
ちょっと工夫してみましょう。

こんなメソッドを作ってみました。
private IEnumerable<T> SelectWithUpdlock<T>(DataContext db, IQueryable<T> query) { var cmd = db.GetCommand(query.AsQueryable()); string s = Regex.Replace(cmd.CommandText, @"(FROM .+ AS [^\s]+)\s", "$1 WITH (UPDLOCK)"); var paras = cmd.Parameters.Cast<IDbDataParameter>().Select(p => p.Value).ToArray(); return db.ExecuteQuery<T>(s, paras); } このメソッドを使うコードは、こんな感じです。
using (var db = new NorthwindDataContext()) { db.Log = Console.Out; var query = from c in db.Customers where c.CustomerID == "ANATR" select c; var result = SelectWithUpdlock(db, query); // ココで呼び出し foreach (var c in result) Console.WriteLine("{0}, {1}, {2}", c.ContactName, c.ContactTitle, c.Phone); } ※ 拡張メソッドにすれば、もっと使いやすくなりますね。

SelectWithUpdlockが、何をやっているかというと、
var cmd = db.GetCommand(query.AsQueryable()); で、queryの実際のSQL文を文字列として取り出しています。
次に、
string s = Regex.Replace(cmd.CommandText, @"(FROM .+ AS [^\s]+)\s", "$1 WITH (UPDLOCK)"); で、SQL文の FORM句の後ろに、"WITH (UPDLOCK)" という文字列を追加した、SQL文を作ります。
３行目の
var paras = cmd.Parameters.Cast<IDbDataParameter>().Select(p => p.Value).ToArray(); ですが、Parametersに入っているパラメータの値を、配列に変換しています。
まず、Castメソッドを使って、Parametersを IEnumerableに
変換し、クエリ演算子が利用できるようにします。そして、Select(p => p.Value)で、
パラメータのシーケンスを取り出し、ToArray()で配列にします。

最後に
、
return db.ExecuteQuery<T>(s, paras); で、クエリを発行し、結果を戻しています。

このSelectWithUpdlockメソッドですが、すべてのクエリ式で試したわけではない
ですが、それなりに動いているみたいです。
かなり、強引な方法ですが、これを応用すれば、LINQ to SQLが対応していないSQL文の実行も、
わざわざSQL文を書かなくても、LINQ to SQL上で実行することが可能になる？かもしれません。

  

まず、LINQ to SQLで更新を行った時に、どのようなSQLが発行されているのか、
以下のコードで見てみましょう。

using (var db = new NorthwindDataContext()) { db.Log = Console.Out; var query = from custmer in db.Customers where custmer.CustomerID == "ALFKI" select custmer; var c = query.SingleOrDefault(); if (c != null) { Console.WriteLine("{0} {1}", c.CustomerID, c.ContactTitle); c.ContactTitle = "Sales Manager"; // ★ db.SubmitChanges(); } }
発行されるSQLは、

UPDATE [dbo].[Customers] SET [ContactTitle] = @p10 WHERE ([CustomerID] = @p0) AND ([CompanyName] = @p1) AND ([ContactName] = @p2) AND ([ContactTitle] = @p3) AND ([Address] = @p4) AND ([City] = @p5) AND ([Region] IS NULL) AND ([PostalCode] = @p6) AND ([Country] = @p7) AND ([Phone] = @p8) AND ([Fax] = @p9)
となります。
SQL の SETで設定されるカラムは、ContactTitleだけです。これからわかるのは、
どのカラムの値が変更されたかで、発行されるSQLが異なるということです。
つまり、動的にSQL文を組み立てているのです。

なかなかすごいことをやっているなと思うのですが、動的にSQLを組み立てること
があだになり、一度に大量のデータを更新するような場合は、SQLの組み立てに
時間がかかり、速度低下が起こる可能性もあります。これは、実際に試していない
ので、僕の想像の域を脱しませんが...

この時に、独自のSQLが使えれば、速度向上につながるかもしれません。
また、あるカラムは更新させたくないといった場合も、独自のSQLが使えれば便利です。

LINQ to SQLは、そのような要望に応えられるよう、Delete, Insert, Update を
既定のものから、別のものに置き換えることができます。
ただし、置き換え後のものは、ストアドプロシージャのみとなります。

では、さっそく、Updateのカスタマイズをやってみましょう。
まず、以下のようなストアドプロシージャを作成します。

CREATE PROCEDURE dbo.UpdateCustmer ( @CustomerID nchar(5), @ContactName nvarchar(30), @ContactTitle nvarchar(30), @Phone nvarchar(24), @Fax nvarchar(24) ) AS UPDATE [dbo].[Customers] SET [ContactTitle] = @ContactTitle, [ContactName] = @ContactName, [Phone] = @Phone, [Fax] = @Fax WHERE ([CustomerID] = @CustomerID)
このストアドプロシージャだと楽観的同時実行制御が行えませんが、
Updateをカスタマイズする方法を示すことが目的なので、そこは大目にみてください。

サーバーエクスプローラの[ストアドプロシージャ]のフォルダを右クリックし、
[新しいストアドプロシージャの追加]を選ぶと、エディタ部にひな形が表示されますので、
それを上記のストアドプロシージャの記述に変更します。
[保存]ボタンを押し、ストアドプロシージャを Northwindデータベースに追加します。

追加されたストアドプロシージャを Northwind.dbml の O/Rデザイナー画面の空白部にD&Dします。
すると、Northwind.dbmlにストアドプロシージャに対応するメソッドが追加されます。

O/RデザイナーのCustomers クラスをクリックし、プロパティウィンドウに、
Customersデータクラスのプロパティを表示します。
Update プロパティに、先ほど作成した UpdateCustomer メソッドを割り当てます。

以上で、Updateメソッドのカスタマイズが完了しました。

これで最初に示したコードを実行すると、

EXEC @RETURN_VALUE = [dbo].[UpdateCustmer] @CustomerID = @p0, @ContactName = @p1, @ContactTitle = @p2, @Phone = @p3, @Fax = @p4
というSQLが発行されているのがわかります。

なお、

c.ContactTitle = "Sales Manager"; c.City = "My City"; db.SubmitChanges();
と Cityカラムを更新しようとしても、ストアドプロシージャには、この値はわたりませんので、
Cityカラムは更新されることはありません。

同様の方法で、Insert, Delete もカスタマイズすることが可能です。

---

LINQ to SQL番外編とは
メールマガジン『C#プログラミングレッスン』で連載した「LINQ to SQL編」には書ききれなかった情報を
「番外編」としてブログにアップしています。
併せて、メールマガジン『C#プログラミングレッスン - Linq to SQL編』も読んでいただけると、
より理解が深まると思います。
バックナンバーは、メールマガジン『C#プログラミングレッスン』書庫のページからダウンロードできます。

  

たぶん、この記事に書いてある情報は、日本語初の情報です。
MSDNライブラリの情報も中途半端で正しい内容ではありません。

前回、変更時の値のチェックについて説明しましたが、エンティティクラス全体の更新時に
データを検証することもできます。
この更新時の検証では、業務アプリケーションの要件に応じて複数のカラムの値を見て、
検証することができます。

以下にNorthwindデータベースを例に、その手順を示します。

1. Visual Studio のソリューションエクスプローラで、プロジェクトに追加されているNorthwind.dbml
   ファイル（LINQ to SQL クラスファイル)を右クリックします。
   
   
2. コンテキストメニューから「[コードの表示] をクリックします。コード エディターが開き、
   NorthwindDataContext の部分クラスが表示されます。
   
   
3. 検証メソッドを作成します。 private void ValidateCustomer(Customer instance) { if (!string.IsNullOrEmpty(instance.ContactTitle) && string.IsNullOrEmpty(instance.ContactName)) { string ErrorMessage = "Invalid data!"; throw new System.Exception(ErrorMessage); } } サンプルコードのため、System.Exception例外を発生させていますが、
   本来は別の例外（あるいは独自例外）を発生させるべきかと思います。
   
   
4. NorthwindDataContextの部分クラスに部分メソッドを追加し、検証コードを呼び出す コードを記述します。
   "partial " までタイプすると、"partial " までタイプすると、インテリセンスが働き、
   メソッド一覧が表示されますので、UpdateXxxxxx を選んでください。Xxxxxx は検証をしたいクラス名です。
   partial class NorthwindDataContext { partial } すると、以下のようなコードが挿入されます。
   partial void UpdateCustomer(Customer instance) { throw new NotImplementedException(); }
5. メソッドに検証メソッドの呼び出しと、DB更新のコードを追加します。
   partial void UpdateCustomer(Customer instance) { ValidateCustomer(instance); this.ExecuteDynamicInsertUpdate(instance); }
6. 同様に、InsertCustomerを追加します。 partial void InsertCustomer(Customer instance) { ValidateCustomer(instance); this.ExecuteDynamicInsertUpdate(instance); }

ExecuteDynamicInsertUpdateメソッドを呼び出すのがカギです。
なぜか、MSDNライブラリの以下のページには、このことが書いてありません。
http://msdn.microsoft.com/ja-jp/library/bb629296.aspx
これで、NorthwindDataContextクラスに検証機能を組み込むことができました。

DBを更新する側のコードを示します。
using (var db = new NorthwindDataContext()) { db.Log = Console.Out; Customer cust = new Customer { CustomerID = "SMPL2", CompanyName = "Sample Corp", ContactName = "Taro", // ★ ContactTitle = "Manager", Country = "Japan" }; db.Customers.InsertOnSubmit(cust); try { db.SubmitChanges(); Console.WriteLine(cust.CustomerID); } catch (Exception ex) { Console.WriteLine(ex.Message); } }
この例では、SubmitChanges メソッドを呼び出すと、InsertCustomer メソッドが呼び出され、
検証ロジックが動いた後、行が挿入されます。
★の行をコメントにして実行すると、検証で例外が発生します。
  

今回は、「LINQ to SQLエンティティクラス」にデータの検証ロジックを追加する方法を 説明します。
検証ロジックを追加することで、特定の列が変更されたときに検証を行う ことが可能になります。
O/Rデザイナーが生成する「LINQ to SQLエンティティクラス」には、いくつかの パーシャルメソッドが用意されており、
このパーシャルメソッドを実装することで、 データの挿入、変更時における検証処理を実現できます。


■検証コードの作成手順

ここでは、（LINQ to SQLエンティティクラスの）CategoryクラスのCategoryNameカラムが
変更された時に、ある検証を行うための手順を示します。

1. O/Rデザイナーで、.dbmlを開きます。
   
   
2. デザイナーに表示されるCategoryクラスを右クリックし、[コードの表示]をク リックします。
   
   
3. 選択したクラスのパーシャルクラスが表示されますので、このクラス内で、 以下のように、"partial " までタイプすると、
   インテリセンスが働き、メソッド一覧が表示されますので、実装したいメ ソッド(OnCategoryNameChanging)を選択してください。
     namespace Gushwell { partial class Category { partial } }
   
4. OnCategoryNameChangingを選択すると、以下のようなコードが挿入されます。
     partial void OnCategoryNameChanging(string value) { throw new System.NotImplementedException(); }
   
5. メソッドに検証ロジックを追加できます。ここでは、すべてが数字ならエラーにしています。
     partial void OnCategoryNameChanging(string value) { if (Array.TrueForAll(value.ToCharArray(), c => Char.IsDigit(c))) throw new System.ArgumentException("Invalid Character"); }

これで、検証ロジックを追加することができました。

■検証ロジックの動作確認

以下のようなコードを書いて、動作を確認してみます。

  var db = new NorthwindDataContext(); var c = db.Categories.Take(1).Single(); c.CategoryName = "1111111"; // ★ db.SubmitChanges();

★の行で、OnCategoryNameChanging()が呼び出され、例外が発生しているのを確認できると思います。
  

ADO.NETの接続型アクセスを使った以下のようなコードがあったとします。

string constr = "Data Source=....."; // 接続文字列 SqlConnection con = new SqlConnection(constr); con.Open(); .... con.Close(); ここにLINQのコードを追加することができます。
DataContextを作成する際に、既存の接続を指定するだけです。
string constr = "Data Source=....."; // 接続文字列 SqlConnection con = new SqlConnection(constr); con.Open(); try { using (var db = new NorthwindDataContext(con)) { var q = from c in db.Categories where c.CategoryName.Length > 6 select c; foreach (var c in q) Console.WriteLine(c.CategoryName); } } finally { con.Close(); } Connectionプロパティを使用して、接続を明示的に閉じることもできます。
db.Connection.Close();   

ADO.NET2.0のTableAdapterでは、GetXxxxxById() などといった独自のメソッドを
追加し、ビジネスロジック層からは、SQL文を意識しないで目的のデータを取得で
きるようにする方法がありました。

LINQ to SQLで同様のことを行う場合は、DataContextにメソッドを追加すること
で、対応できます。
コードジェネレータは用意されていないので、手動で追加することになります。


今回は、「ProductIDを指定しProductオブジェクトを取得する」メソッドを追加してみましょう。

1. Northwind.dbmlのO/Rデザイナーを開きます。

2. デザイナーの空白部分を右クリックし、[コードの表示]を選択します。

3. パーシャルクラス NorthwindDataContext が表示されますので、ここでGetProductById()メソッドを追加します。

partial class NorthwindDataContext { public Product GetProductById(int productId) { return this.Products.Single(p => p.ProductID == productId); } }
もちろん、このメソッド内で、ストアドプロシージャを呼び出すことも可能です。
  

前回の記事でUpdateCheckプロパティについて触れましたが、もう少し詳しくこの
UpdateCheckについてみていきましょう。

このプロパティは、LINQ to SQL がオプティミスティック同時実行競合を検出する方法を
取得または設定するものです。以下の３つの列挙値を利用できます。

1. Always　 競合の検出に常にこの列を使用します。


2. Never　 競合の検出にこの列を使用しません。


3. WhenChanged　 メンバーがアプリケーションによって変更された場合のみ、この列を使用します。

既定値は、Alwaysです。

このプロパティ値を変更することで、オプティミスティック同時実行競合を検出
する方法を変更することができます。

このプロパティ値を変更する手順を示します。

1. ソリューションエクスプローラで、Northwind.dbmlをダブルクリックし、O/Rデザイナー画面を開きます。


2. エンティティクラスのプロパティ（以降メンバーと呼びます）をマウスでクリックします。


3. プロパティウィンドウに、このメンバーに対応したプロパティが表示されます。


4. [更新チェック]プロパティの値をAlways, Never, WhenChanged から選択します。

この操作をやることで、Northwind.designer.csの 該当プロパティ（メンバー）
のColumn属性のUpdateCheckプロパティの値が変更されます。

なお、このプロパティが有効なのは、どのメンバーも、IsVersion=true として指定されていない場合だけです。

いずれかのメンバーに、IsVersion=true が指定されている場合、UpdateCheckは無効となります。
  

中断していた「LINQ to SQL番外編」を再開します。

LINQ to SQLでは、楽観的同時実行制御の仕組みが組み込まれています。
たとえば、Customers テーブルの行を更新する場合、LINQ to SQLは
以下のような UPDATE文を発行します。
UPDATE [dbo].[Customers] SET [ContactName] = @p10 WHERE ([CustomerID] = @p0) AND ([CompanyName] = @p1) AND ([ContactName] = @p2) AND ([ContactTitle] = @p3) AND ([Address] = @p4) AND ([City] = @p5) AND ([Region] IS NULL) AND ([PostalCode] = @p6) AND ([Country] = @p7) AND ([Phone] = @p8) AND ([Fax] = @p9)
パラメータ p0, p1, p2... には、変更前の値が渡されます。
このSQLは、他のユーザによって変更されていない場合にだけ、このUPDATE文
が成功することになりますので、他のユーザによる変更有無を把握できるわけです。

LINQ to SQLでは各カラムに規定値として、
UpdateCheck = UpdateCheck.Always
が設定されています。これにより上記SQLのWHERE句で変更チェックが行われることになります。

しかし、すべてのカラムで変更有無のチェックすることは、パフォーマンスに影響することもあります。
なのでもっと単純な方法でこの制御を行いたい場合もあります。

そのような場合で一般的なのは、Timestamp型のカラムをテーブルに追加することです。
Timestamp型がテーブルにあると、O/Rデザイナーはカラム属性のIsVersionプロパティに
Trueが設定されます。これにより、競合の発生の判断に
Timestamp型のカラムのみが利用されることになります。

O/Rデザイナーが付加する属性を以下に示します。(TimeStampという名前のカラムにしています)

[Column(Name="TimeStamp", Storage="_TimeStamp", AutoSync=AutoSync.Always, DbType="rowversion", IsDbGenerated=true, IsVersion=true, UpdateCheck=UpdateCheck.Never)] public System.Data.Linq.Binary TimeStamp { ... } また、

この場合のUPDATE文は、

UPDATE [dbo].[Customers] SET [ContactName] = @p2 WHERE ([CustomerID] = @p0) AND ([TimeStamp] = @p1) となり、主キーとTimeStampカラムだけが、チェックされる単純なSQL文となります。

最近では、GUIDをカラムに追加して、同様のことを行うこともあるようですが、
LINQ to SQLがサポートしているかどうかまでは、調べきっていません。
ご存知の方がいましたら、コメントいただけると嬉しいです。

  

NorthwindデータベースのEmployeesテーブルの ReportsTo列は、NULLを許可する 型として定義されています。
そのため、「LINQ to SQLエンティティクラス」の Employee.ReprotsToプロパティも、

public System.Nullable<int> ReportsTo { ... }
と、Northwind.designer.csに書かれています。

System.Nullableは、int? と同じ意味です。

これがわかれば、クエリ式を書くのもそう難しいことではありません。

using (var db = new NorthwindDataContext()) { db.Log = Console.Out; var query = from emp in db.Employees where emp.ReportsTo.HasValue select emp; foreach (var emp in query) { Console.WriteLine("{0} {1}, {2}", emp.FirstName, emp.LastName, emp.ReportsTo); } }
ReportsToがNULLのものだけ取得したいのなら、

var query = from emp in db.Employees where !emp.ReportsTo.HasValue select emp;
と書けばOKです。

では、Customersテーブルの Fax列（NULLを許可しています）は、どうでしょうか？。
Fax列は、「LINQ to SQLエンティティクラス」のCustomer.Faxでは、C#のString 型にマッピングされています。
System.Nullable とはなっていません。
string型は参照型で、もともとnullを保持できますから、そのままでOKということです。
というか、文法上、System.Nullable とすることはできません。

ですから、

using (var db = new NorthwindDataContext()) { db.Log = Console.Out; var query = from c in db.Customers where c.Fax == null select c; }
と書けば、Fax番号が登録されていない顧客だけを抜き出すことができます。
  

IDENTITY列の扱い テーブルに行を挿入した際に、自動で番号を振りたい場合に、列にIDENTITYを指定すると便利ですが、
挿入直後にこの値を取得したい場合に、LINQ to SQLはとても便利な機能を備えています。

主キーにIDENTITYを指定したカラムについて、O/Rデザイナーが作成する「LINQ to SQLエンティティクラス」の
プロパティがどうなっているのかを見てみましょう。

NortwindデータベースのCategoryテーブルのCategoryIDカラムがこれに該当します。
Northwind.designer.csを開いて、CategoryクラスのCategoryIDプロパティを見て ください。
以下のような記述があるのを確認できると思います。
[Column(Storage="_CategoryID", AutoSync=AutoSync.OnInsert, DbType="Int NOT NULL IDENTITY", IsPrimaryKey=true, IsDbGenerated=true)] public int CategoryID 注目すべきは、
AutoSync=AutoSync.OnInsert, の部分です。この指定があると、行が挿入されると自動で、CategoryIDカラムを 取得する select文が発行されます。

そのため、
var c1 = new Category { .... }; db.Categories.InsertOnSubmit(c1); db.SubmitChanges(); Console.WriteLine(c1.CategoryID); というコードを実行すれば、SubmitChanges()後の、c1.CategoryIDには、データ ベースで
生成された値を参照することができます。

わずらわしいコーディングから解放されるのは、とても嬉しいですね。
ただ、２つのSQL文がリクエストされるのは避けたいという場合には、 ストアドプロシージャを利用することも検討してください。
  

DataContext の CreateDatabase() メソッドを呼び出すことで、データベースの
新しいインスタンスを作成することが可能です。
「LINQ to SQLエンティティクラス」には、データベースのテーブルやカラムに関する
属性があるので、この情報を利用して、データベースのインスタンスを作成します。


「LINQ to SQLエンティティクラス」の定義

ここでは、方法 : データベースを動的に作成する (LINQ to SQL)に記載されている「LINQ to SQLエンティティクラス」を拡張し、
リレーショナル構造をもった「LINQ to SQLエンティティクラス」を定義してみました。

上記記事の例との意違いは、
・Categoriesテーブルを追加
・DVDテーブルに、CategoryIDカラムを追加
・DVDテーブルと、Categoriesテーブルを関連づけ
です。
namespace CreateDatabaseSample { [Table(Name = "dbo.DVDTable")] public class DVD { private EntityRef<Category> _Category; [Column(IsPrimaryKey = true)] public string Title; [Column] public string Rating; [Column(DbType = "Int")] public System.Nullable<int> CategoryID; [Association(Name = "Category_DVD", Storage = "_Category", ThisKey = "CategoryID", IsForeignKey = true)] public Category Category { get { return this._Category.Entity; } set { this._Category.Entity = value; this.CategoryID = value.CategoryID; } } } [Table(Name = "dbo.Categories")] public partial class Category { [Column(IsPrimaryKey = true, IsDbGenerated = true)] public int CategoryID; [Column(DbType = "NVarChar(15) NOT NULL", CanBeNull = false)] public string CategoryName; [Association(Name = "Category_DVD", OtherKey = "CategoryID")] public EntitySet<DVD> DVDs; } }
DataContextの定義

DataContextを継承し、カスタムのDataContextクラスを定義します。DataContext派生クラスには、
作成する上記テーブルをメンバーとして宣言します。
public class MyDVDs : DataContext { public Table<DVD> DVDs; public Table<Category> Categories; public MyDVDs(string connection) : base(connection) { } }
データベースを作成するコード

以下、データベースを作成するコードです。
この例では、DatabaseExists()で、データベースの存在を確認し、存在していた場合は、
DeleteDatabase()で、データベースを削除後、CreateDatabase()でデータベースを
作成するようにしています。
class Program { static void Main(string[] args) { MyDVDs db = new MyDVDs(@".\SQLEXPRESS"); if (db.DatabaseExists()) db.DeleteDatabase(); db.CreateDatabase(); } }
  

DataContextは、エンティティオブジェクトの変更を追跡していますが、データベースから
データを読み込むだけで、更新を行う必要がないシナリオが多く存在します。
そのようなときには、DataContextに、エンティティへの変更を追跡しないように指示することで、
パフォーマンスを向上させることができます。
その指示は、ObjectTrackingEnabledプロパティを使います。
db.ObjectTrackingEnabled = false; これだけです。

※ 変数 db は、DataContext型のオブジェクトを表します。

もちろん、この状態で、SubmitChanges()することは出来ません。呼び出した時点で例外が発生します。
  

NorthwindDataContextのコンストラクタでは、OnCreateというメソッドを呼び出しています。
public NorthwindDataContext() : base(global::FirstApp.Properties.Settings.Default. NORTHWNDConnectionString, mappingSource) { OnCreated(); }
これってなんでしょうか？
Northwind.designer.csのNorthwindDataContextクラスの定義を見てみると、
public partial class NorthwindDataContext : System.Data.Linq.DataContext { private static System.Data.Linq.Mapping.MappingSource mappingSource = new AttributeMappingSource(); #region Extensibility Method Definitions partial void OnCreated(); partial void InsertProduct(Product instance); partial void UpdateProduct(Product instance); partial void DeleteProduct(Product instance); #endregion ...
とパーシャルメソッドとなっています。

つまり、NorthwindDataContextのパーシャルクラスに、OnCreated()メソッドを定義すれば、
このメソッドが、NorthwindDataContextインスタンス生成時に呼び出されるということです。

試しに、OnCreatedメソッドを実装してみましょう。

プロジェクトに、クラスの追加で、NorthwindDataContext.csというファイルを新規作成し、
そこに、以下のように記述します。
public partial class NorthwindDataContext : System.Data.Linq.DataContext { partial void OnCreated() { Console.WriteLine("NorthwindDataContext Created"); } } これで、再度ビルドし実行すれば、
var db = new NorthwindDataContext(); が実行された時点で、

 NorthwindDataContext Created

とコンソールに出力されることがわかると思います。
この機能を使うことで、ログ出力などのカスタムコードを挿入することが可能になります。

その他のパーシャルメソッドについても、カスタムコードを挿入する際に利用できるものだと
思いますが、調べきれていません。
もし、気が向いたら調べたいと思います。
  

DataContext は、データベースからオブジェクトを取得したり、変更を再送信したりする際に使用するクラスで、LINQ to SQLの最も中心となるクラスです。

Visual Studio のO/Rデザイナー画面で、「LINQ to SQLエンティティクラス」を作成すると、必ず、DataContextから派生したカスタムクラスのコードが作成されます。
DBにアクセスするには、次のように、派生したDataContextクラスのインスタンスを生成し、データベースにアクセスする準備をします。

var db = new NorthwindDataContext();
Northwind.designer.csのソースコードの中の、NorthwindDataContextクラスを見てみると、そのコンストラクタに、

public NorthwindDataContext() : base(global::FirstApp.Properties.Settings.Default. NORTHWNDConnectionString, mappingSource) { OnCreated(); }
※都合により途中で改行しています。

と書いてあります。
ADO.NET2.0と同様に、Settings.settingsに設定した接続文字列を使い、データベースに接続しているのが分かります。
通常は、App.Configの connectionStringsで指定した接続文字列が使われますが、
このApp.Configが無い場合には、ソースに埋め込まれた接続文字列が使われます。
なんかややこしい作りです。
第2引数のmappingSourceについては、僕自身まだ使ったことがなく、よく分かっていませんm(_ _)m

なお、
string constr = "...."; var db = new NorthwindDataContext(constr);
と、デフォルトの接続文字列以外を利用することもできます。
これは、ADO.NET2.0より、使いやすくなっていますね。
  

DataContextのインスタンス生成にはそれほどコストはかかりませんので、
論理的な処理単位に対して生成、破棄をすることになります。
通常は、メソッドのスコープで生成、破棄することが多いかと思います。

この一連の記事(メルマガとこの番外編の記事）では、
以下のようにその都度NorthwindDataContextを生成するようになっています。
using (var db = new NorthwindDataContext()) { ... } これは、コードをコピー＆ペーストした際に、そのまま動くよう配慮したということもありますが、
実際のコードにおいても、小さな処理単位で、DataContext を使うことが多いと予想されるから
という意味もあります。
  

パラメータだけが異なる同じクエリを何回も実行することはよくありますが、その ような場合、
クエリをコンパイルしてから、そのクエリを実行することでパフォー マンスを向上させることができます。

まず、以下のような、CompiledQuery.Compileを使い、デリゲート型のフィールド を定義します。
Compile メソッドは、入力パラメータを変更するだけで、
その後、何度も実行で きるキャッシュ可能なデリゲート型を返します。
using System.Data.Linq; ... static public Func<NorthwindDataContext, string, IQueryable<Product>> ProductByName = CompiledQuery.Compile((NorthwindDataContext db, string name) => from p in db.Products where p.ProductName.StartsWith(name) == true select p );
この例では、nameがクエリのパラメータになります。
ProductByNameにはコンパイル済みクエリが格納されます。このコンパイル済みク エリを使うには、

using (var db = new NorthwindDataContext()) { var q = ProductByName(db, "Sir"); foreach (var p in q) Console.WriteLine(p.ProductName); } のように書きます。
ここでは、パラメータは、nameひとつだけでしたが、もちろん、複数のパラメータ を渡すこともできます。

以下のようにラムダ式と var を使って書くこともできます。
var query = CompiledQuery.Compile( (NorthwindDataContext db, string name) => from p in db.Products where p.ProductName.StartsWith(name) == true select p ); using (var db = new NorthwindDataContext()) { foreach (var p in query(db,"Sir")) Console.WriteLine(p.ProductName); } デリゲートをいちいち定義するのも面倒なので、この書き方が良いかなと思ったり しましたが、
実際には、このコンパイル済みクエリは、何度も再利用することで効 果が得られますので、
上のようにローカル変数にして使うことは、あまり無いかなと思 います。
  

メールマガジン『C#プログラミングレッスン』で 今年の６月から「LINQ to SQL編」
を連載していますが、LINQ to SQLの全容を解説するには、あまりにも長期にわた
ってしまうため、一部の内容をメールマガジンに書くのを断念しました。
そのため、メールマガジンに書けなかった内容をこのブログで
紹介してゆくことにします。

なお、ここで書く内容は、メールマガジン『C#プログラミングレッスン』で説明した
内容を理解している事を前提にしています。
併せて、メールマガジン『C#プログラミングレッスン - Linq to SQL編』も読んで
いただけると、より理解が深まると思います。
バックナンバーは、後日、メールマガジン『C#プログラミングレッスン』書庫のページから
ダウンロードできるようにする予定ですが、
それまでは、「ここ」とか「ここ」を見てください。

では、次の記事から、「LINQ to SQL 番外編」の始まります。