WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

SqlCommand の Dispose は呼ぶべきか?

by WebSurfer 2013年4月23日 13:58

結論は呼ぶべきなのですが、そのあたりのことについて調べて新発見があったので、備忘録として書いておきます。

SqlConnection クラスの Close メソッド(Dispose と機能的に同じ)を明示的に呼び出して接続を閉じることは、リソースリーク防止のため重要であることはよく知られていると思います。

詳しくは、.NETの例外処理 Part.2 を見てください。特に、そのページに書かれている、"GC の仕組みで防がれるリークはメモリリークである、という点です。実は、アプリケーションにおけるリークには大別してメモリリークとリソースリークがあり、リソースリークは GC のみで防止することができません。" という点に注目です。

では、SqlCommand クラスや SqlDataReader クラスの場合はどうでしょうか? MSDN ライブラリのサンプルコードでも Dispose メソッドを呼び出してないケースが多々見られます。SqlConnection クラスと違ってリソースリークの問題はなさそうですが、メモリリーク防止のため Dispose メソッドを呼び出す必要はないのでしょうか?

MSDN ライブラリの Dispose メソッドの実装 を見ると、"マネージリソースのみを使用する型は、ガベージコレクターによって自動的にクリアされるため、このような型で Dispose メソッドを実装しても、パフォーマンス上の利点はありません。" とのことです。(.NET 4.6 / 4.5 の記事にはその説明はありませんが同じことかと思います)

ということは、アンマネージリソースを使用していない SqlCommand などでは、Dispose メソッドを呼び出してもパフォーマンス上の利点はないということになってしまいます。

しかし、実は、Dispose メソッドには、メモリ開放の機能以外に、GC.SuppressFinalize メソッド を実装することにより、冗長なファイナライザーの呼び出しを防ぐことができるという利点があるそうです。

そのあたりは、MSDN フォーラムの Should I call Dispose on a SQLCommand object? というページで、Microsoft (MSFT) の方が "To prevent a finalizer from running, most well written Dispose implementations call a special method called GC.SuppressFinalize, which indicates to the GC that its finalizer shouldn't be run when it falls out of scope (as the Dispose method did the clean up). The component class (which remember the SqlCommand indirectly inherits from), implements such a Dispose method. Therefore to prevent the finalizer from running (and even though it does nothing in the case of SqlCommand), you should always call Dispose." と述べてられている通りだと思います。

また、Dispose メソッドの実装 の説明にも、"Dispose メソッドは、破棄するオブジェクトの SuppressFinalize メソッドを呼び出す必要があります。 SuppressFinalize を呼び出すと、オブジェクトが終了キューに置かれている場合は、そのオブジェクトの Finalize メソッドの呼び出しは行われません。Finalize メソッドの実行は、パフォーマンスに影響を与えることを覚えておいてください。" と書かれています。(.NET 4.6 / 4.5 の記事にはその説明はありませんが同じことかと思います)

という訳で、結論は、IDisposable インターフェイス を継承して Dispose メソッドを実装しているクラスは、そのオブジェクトが使用されなくなった時点で Dispose メソッドを呼び出すべきということのようです。

そのために良く使われるのが、上に紹介した .NETの例外処理 Part.2 にある try/finally パターンや using ステートメントですね。

using ステートメントを使用すると、以下の例のようになると思います。

using(SqlConnection conn = new SqlConnection("接続文字列"))
{

  conn.Open();

  using(SqlCommand cmd = new SqlCommand("クエリ", conn))
  {
    using (SqlDataReader reader = cmd.ExecuteReader())
    {
      if (reader != null)
      {
        while (reader.Read())
        {
          // 何らかの処置
        }
      }
    } // SqlDataReader の Dispose(注1)

  } // SqlCommand の Dispose

} // SqlConnection の Dispose(注2)

注1:Dispose メソッドは、SqlDataReader によって使用されているリソースを解放し、Close メソッドを呼び出します。

注2:SqlConnection クラスの Close メソッドと Dispose メソッドは、機能的に同じです。

------ 2014/9/25 追記 ------

クラスによってはコンストラクタに GC.SuppressFinalize メソッドが実装されており、冗長な Finalize メソッドの呼び出しを防ぐという意味では Dispose() メソッドを呼ぶ必要はないものもあります。

実は、SqlCommand クラスの場合も、現時点のソースコードを見る限り、コンストラクタに GC.SuppressFinalize メソッドが実装されています。

ただし、コンストラクタでの GC.SuppressFinalize の実装は MSDN ライブラリなどにはドキュメント化されてない(ソースコードを見ないと分からない)、ソースコードは変更される可能性がある、将来ネイティブリソースが含まれる可能性はゼロではない(ゼロに近いとは思いますが)・・・ということを考えるべきです。

なので、IDisposable を継承するクラスは Dispose() を呼ぶべきというのが基本ルールであると思っています。

------ 2015/9/11 追記 ------

リンク先の MSDN ライブラリの記事を .NET Framework 4 のものに固定しました。URL にバージョンを指定しないと .NET 4.5 / 4.6 の MSDN ライブラリにリンクされますが、その記述が .NET 4 のものかなり異なっていて、.NET 4 をベースに書いた上の記事とミスマッチが生じましたので。

Tags: ,

ADO.NET

パラメータ d の値を復号

by WebSurfer 2013年4月12日 15:15

WebResource.axd や ScriptResource.axd のクエリ文字列のパラメータ d の値を復号化する方法を備忘録として書いておきます。

パラメータ d の値を復号

利用目的は、WebResource.axd や ScriptResource.axd に指定されているリソースを特定するためです。クエリ文字列のパラメータ d にはリソースが指定されています。しかし、パラメータ d は暗号化されているため、リソースを特��するためには復号しなければなりません。

内容は、先の記事「WebResource.axd の HTTP 404 エラー」で紹介したページのコードとほとんど同じですが、リンク切れになると困るので、主要な部分のみ抜き出しました。

上の画像を表示したコードは以下の通りです。このページを運用環境に含めたり、一般に公開したりすると、セキュリティ上の問題が生ずる恐れがありますので注意してください。

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Web.Configuration" %>
<%@ Import Namespace="System.Reflection" %>
<%@ Import Namespace="System.Text.RegularExpressions" %>
<%@ Import Namespace="System.Text" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
  protected void Button1_Click(object sender, EventArgs e)
  {
    string input = TextBox1.Text;
    if (string.IsNullOrEmpty(input))
    {
      Label1.Text = string.Empty;
      Label2.Text = string.Empty;
      return;
    }

    string pattern = "d=(?<param>[^&]+)&";
    Match match = Regex.Match(input, pattern);
    if (!match.Success)
    {
      Label1.Text = string.Empty;
      Label2.Text = string.Empty;
      return;
    }
    GroupCollection groups = match.Groups;
    string data = groups["param"].Value;        

    byte[] encryptedData =
        HttpServerUtility.UrlTokenDecode(data);
    if (encryptedData == null)
    {
      Label1.Text = data;
      Label2.BackColor = System.Drawing.Color.Red;
      Label2.Text = "無効なパラメータ";
      return;
    }
        
    Type machineKeySection = typeof(MachineKeySection);
    Type[] paramTypes = new Type[] { typeof(bool), 
                                     typeof(byte[]), 
                                     typeof(byte[]), 
                                     typeof(int), 
                                     typeof(int) };
    MethodInfo methodInfo = machineKeySection.GetMethod(
            "EncryptOrDecryptData",
            BindingFlags.Static | BindingFlags.NonPublic,
            null,
            paramTypes,
            null);

    try
    {
      byte[] decryptedData = (byte[])methodInfo.Invoke(
                null,
                new object[] { false, 
                               encryptedData, 
                               null, 
                               0, 
                               encryptedData.Length });

      string decrypted = Encoding.UTF8.GetString(decryptedData);
      TextBox1.Text = string.Empty;
      Label1.Text = data;
      Label2.BackColor = System.Drawing.Color.Lime;
      Label2.Text = decrypted;
    }
    catch (TargetInvocationException)
    {
      TextBox1.Text = string.Empty;
      Label1.Text = data;
      Label2.BackColor = System.Drawing.Color.Red;
      Label2.Text = "復号に失敗";
    }
  }
</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
  <title>d パラメータを復号</title>    
</head>
<body>
  <form id="form1" runat="server">
  <div>
    URL をコピー&ペースト
    <asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
    <asp:Button ID="Button1" 
      runat="server" Text="復号" OnClick="Button1_Click" />
    <hr />
    <asp:Label ID="Label1" runat="server"></asp:Label>
    <br />
    <asp:Label ID="Label2" runat="server"></asp:Label>
  </div>
  </form>
</body>
</html>

Tags:

ASP.NET

EditorFor と DisplayFor の違い

by WebSurfer 2013年3月27日 21:38

Html Helper の EditorFor と DisplayFor が、POST 要求に対する応答で、異なった値を表示することがあります。その理由と解決策を備忘録として書いておきます。

EditFor と DisplayFor の違い

上の画像を表示した Model, View, Controller のコードは以下の通りです(説明に関係ない部分は省略してあります)。

Model

public class FileModel
{
  public string FileName { get; set; }
}

View

@model MvcApplication1.Models.FileModel

@using (Html.BeginForm())
{
  @Html.EditorFor(m => m.FileName)
  <input type="submit" value="POST" />
  @Html.DisplayFor(m => m.FileName)
}

Controller

public class FileController : Controller
{
  [HttpPost]
  public ActionResult Index(FileModel m)
  {
    m.FileName += ".ext";
    return View(m);
  }
}

ユーザーがテキストボックス(EditorFor 相当)にファイル名を入力し、form を submit(POST 要求)すると、Controller で model の FileName プロパティに拡張子 ".ext" を追加します。

この場合、応答画面では、DisplayFor には拡張子 ".ext" が追加されて表示されるものの、EditorFor には ".ext" は追加されません。 上の画像の例を見てください。

つまり、EditorFor には POST された値がそのまま使われています。

何故そうなるかと言うと、例えば、EditorFor の入力にユーザーが間違った値を入力した場合、サーバーに POST された時に検証 NG とし、エラーメッセージ(例:入力が間違っています)を表示するとともに、EditorFor にはユーザー入力をそのまま表示したいという理由だそうです。

具体的には、POST された値は ModelState ディクショナリ(model ではない)に格納されていて、Html Helper はまず ModelState ディクショナリを調べて、そこに値があればそれを表示するようになっています。

詳しくは以下のページを見てください。

ASP.NET MVC’s Html Helpers Render the Wrong Value!

value が POST されるか否かが問題になります。例えば、EditorFor に限らず、HiddenFor もその value は POST されるので、結果は EditorFor と同じになります。

一方、DisplayFor には、POST される value などというものはないので、model の値が使われます。

EditorFor にも DisplayFor と同様に model の値(拡張子 .ext が追加されたもの)を表示するには、ModelState ディクショナリを Clear することです。

そうすれば model から値を取ってくるので、期待した結果になります。具体的には以下のコードを追加します。

if (ModelState.IsValid)
{
  ModelState.Clear();
}

ただしこのようにして、検証結果 OK で POST 要求への応答をそのまま返すのは、二重 POST の問題が起こりうるので、好ましくないようです。

二重 POST 問題

MVC に限らず、Web アプリケーション開発の基本として、Post/Redirect/Get (PRG) パターンを使う・・・即ち、POST 要求への応答をそのまま返すのは検証結果 NG の場合のみとし、検証結果 OK の場合は、例え同じページを表示するにしても、リダイレクトしてブラウザに GET 要求させるのがよいそうです。(詳しくはリンク先を見てください)

Post/Redirect/Get による問題解決

Post/Redirect/Get パターンを使うように、上記のコードを書き直すと、以下のようになると思います。

public class FileController : Controller
{
  [HttpGet]
  public ActionResult Index()
  {
    FileModel model;

    object obj = TempData["ValidationResult"];
    if (obj is FileModel)
    {
      // 検証 OK ⇒ 再確認
      model = (FileModel)obj;
    }
    else
    {
      // 初期画面
      model = new FileModel();
    }
    return View(model);
  }

  [HttpPost]
  public ActionResult Index(FileModel m)
  {
    if (ModelState.IsValid)
    {
      // 検証 OK ⇒ 再確認
      m.FileName =
        ModelState["FileName"].Value.AttemptedValue
        + ".ext";
      TempData["ValidationResult"] = m;
      return RedirectToAction("Index");
    }
    else
    {
      // 検証失敗
      return View(m);
    }
  }
}

Tags:

MVC

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年5月  >>
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

View posts in large calendar