テスターですが何か?

ホビープログラマ略してHPです

Archive for the ‘ASP.NET MVC’ Category

ASP.NET MVCのクラスの作り方を考えてみた(4)

leave a comment »

前回のブログエントリーでUnityでのインターフェースと型のマッピングがC#には書けず、設定ファイルに書かなければならないという内容を書きましたが、実はC#にもマッピングの設定を記述することができます。あまりに自分が無知ですみません。このブログエントリーを見て気づきました。

IoCフレームワーク、クラスとConfigファイルの両方から設定する (miso_soup3さん)

設定方法は、UnityContainer.ResisterTypeでインターフェースと型を登録します。C#で設定を行うのでintellisenseが効いてタイプミスを防ぐことができます。Global.asax.csのApplication_Startにはこのように記述します。UnityContainer.LoadConfigurationをコメントアウトしているのは、設定ファイルを作成しているとこのメソッドを呼び出した際に設定が上書きされてしまうためです。

IUnityContainer container = new UnityContainer();

 

// Unity用マッピング設定

container.RegisterType<IHogeWorkerService, HogeWorkerService>();

container.RegisterType<IHogeDao, HogeDao>();

//container.LoadConfiguration();

 

IDependencyResolver resolver = new UnityDependencyResolver(container);

DependencyResolver.SetResolver(resolver);

 

C#でUnityのマッピング設定を行うことができることがわかったので、もう使わない手はないですね。DIなしで単体テストを行うなんて狂気の沙汰ですから。(単体テストを行わないなんてもっと 以下略) #if debugを使用すればテスト用とRelease用の設定も分けることが(たぶん)できるでしょうし。やっぱり個人的にはUnityを使う場合はC#でマッピングの設定を書きたいですね、設定ファイル地獄はC#の文化には合わないと思います。

今回はUnityをテーマに書きました。作成したソースはSkyDriveにアップしてあります。「MvcHogeApp_v4」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 2012 Express for Webがインストールされた環境で開いてください。

Written by david9142

2012年8月4日 at 11:39 PM

カテゴリー: ASP.NET MVC

Tagged with ,

ASP.NET MVCのクラスの作り方を考えてみた(3)

leave a comment »

何回シリーズになるか分かりませんが、「プログラミング ASP.NET MVC」を読んでASP.NET MVCのクラス構成について考えた記事を書いています。これまで2回書いており、内容は以下の通りです。

第3回目はpatterns&practicesのProject Silkで利用されているUnityを利用したDIについて書きます。Unityは制御の反転(IoC:Inversion of Control)を実現するためのフレームワークです。IoCとはDIの1つ上、抽象化された概念だと思ってください。IoCを実現するための実装の1つがDIになります。(用語や概念を厳密に説明できるほど理解が進んでいないです)詳しいことを知りたい方は、以下のページを良く読んでください。

制御の反転

Unity におけるポリシーの挿入

Project SilkやUnityについてはすでにブログで書いている方がいらっしゃるので、最大限参考にさせていていただきました。

ASP.NET MVC 3 と Unity の組み合わせを試し中 (shibayanさん)

Project SilkにならってUnityを使ってみる (miso_soup3さん)

今回は(2)で作成したソースをUnityに対応させたいと思います。まずはNugetでインストールします。

PM> Install-Package Unity
依存関係 ‘CommonServiceLocator (≥ 1.0)’ の解決を試みています。
‘CommonServiceLocator 1.0’ が正常にインストールされました。
Unity を Microsoft patterns & practices からダウンロードします。このライセンス条項は http://www.opensource.org/licenses/ms-pl で参照できます。固有のライセンス条項がある追加の依存関係がパッケージに含まれていないかどうかを確認してください。パッケージおよび依存関係を使用することで、該当するライセンス条項に同意したものとみなされます。ライセンス条項に同意しない場合は、関係のあるコンポーネントをデバイスから削除してください。
‘Unity 2.1.505.0’ が正常にインストールされました。
‘CommonServiceLocator 1.0’ が MvcHogeApp に正常に追加されました。
‘Unity 2.1.505.0’ が MvcHogeApp に正常に追加されました。

Web.configにインターフェースと実装クラスのマッピング設定を記述します。

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <configSections>

    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>

  </configSections>

  <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">

    <namespace name="MvcHogeApp" />

    <namespace name="MvcHogeApp.WorkerService" />

    <namespace name="MvcHogeApp.Models" />

    <assembly name="MvcHogeApp" />

    <container>

      <register type="IHogeWorkerService" mapTo="HogeWorkerService" />

      <register type="IHogeDao" mapTo="HogeDao" />

    </container>

  </unity>

</configuration>

 

Project SilkではWeb.configではなく専用の設定ファイル(Unity.config)にマッピング情報を記載していました。また<register>タグで指定するマッピング情報では名前空間を省略せずに書いてありました。

次にリゾルバの設定です、なぜかIDependencyResolverインターフェースを実装した、欲しいインスタンスを取得するリゾルバが提供されていないので、自分でコードを書く必要があります。今回はProjet Silkで実装されている「UnityDependencyResolver.cs」をそのまま利用しました。このとき知ったのは、Unity関連のクラスはMicrosoft.Practices.Unity名前空間にあるんですね。Unityがルートじゃないんですね。

そしてリゾルバの設定です、Global.asax.csのApplication_Startに設定を行います。

protected void Application_Start()

{

    IUnityContainer container = new UnityContainer();

    container.LoadConfiguration();

 

    IDependencyResolver resolver = new UnityDependencyResolver(container);

    DependencyResolver.SetResolver(resolver);

}

 

こうすることで、引数なしのコンストラクタが不要になります。Web.configに記載したマッピングの設定にしたがってUnityがインスタンスを取得してくれるためです。コードはこうなります。(わかりやすくするために、以前のコードも残してあります)多少コードがすっきりしたことがわかると思います。

public class HogeWorkerService : IHogeWorkerService

{

    private IHogeDao Dao;

 

    // 通常のコンストラクタ

    //public HogeWorkerService()

    //{

    //    Dao = new HogeDao();

    //}

 

    // DI(コンストラクタインジェクション)コンストラクタ

    public HogeWorkerService(IHogeDao dao)

    {

        Dao = dao;

    }

 

    // コントローラーから呼び出されるメソッド

    public HogeViewModels MakeHoge()

    {

        // 省略

    }

 

今まで通り、引数付きのコンストラクタは単体テスト用に必要です。

Unityを使った感想ですが、それほどDIフレームワークを利用するメリットが思いつかないです。コードがややすっきりするのは確かですが、デフォルトコンストラクタがなくなるだけなので、それほど劇的に変わりません。逆に、設定ファイルに型・インターフェース名を文字列として記載するのでタイプミスでエラーが発生してハマるリスクのほうが大きい気が...(昔S2Containerのdiconファイルの記述でハマった悪夢が蘇りました)

ただ、Release/Debug用に設定ファイルを分けることで、取得するインスタンスを切り替えることができますし、単体テストプロジェクトにも設定ファイルを作成して、リゾルバを設定することで引数付きコンストラクタもなくすことができると思います。(Project Silkではそこまでやっていませんでしたが)使うのであれば、プロダクションコード、テストプロジェクトまで徹底的に使わないと、使い方を覚えるコストをペイできないんじゃないかなぁ、と思いました。手放しで「素晴らしい!」とは言えませんでした。う~ん。

Unityの単純な使い方ではなくて、シナリオがあってUnityを使うとこんなに素晴らしくなるという説明を誰かブログに書いてくれないですかねぇ。自分は書けませんでした。

今回はUnityをテーマに書きました。作成したソースはSkyDriveにアップしてあります。「MvcHogeApp_v3」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

 

Written by david9142

2012年7月15日 at 5:36 PM

カテゴリー: ASP.NET MVC

Tagged with ,

ASP.NET MVCのクラスの作り方を考えてみた(2)

leave a comment »

前回のエントリーでざっくりしたクラス構成を作成しました、今回はそれに対する単体テストコードを作成します。

前回作ったASP.MVCのコードは以下の構成になっていました。

  • Controllerが呼び出すコーディネーター的な役割のWorkerServiceクラスを作成
  • DI(コンストラクタインジェクション)でインターフェースと実装を分離

今回単体テストを実装するにあたっての前提は以下のとおりです

  • 単体テストフレームワークはMSTestを使用します(Visual Studio 2012 Express for Webに同梱)
  • Mock用フレームワークはMoqを使用します

本当、ホビープログラマーがVisual Studioから単体テストを実行できる時代が来るとは思いませんでした。Visual Studio 2012 Expressには単体テスト機能が含まれています、Visual Web Developer 2010+Nunitで開発するなら、Visual Studio 2012 Express for Webを使いましょう。

まずはNugetを使ってソリューション作成時にあわせて作成したテストプロジェクトにパッケージをインストールします。

PM> Install-Package Moq
‘Moq 4.0.10827’ は既にインストールされています。
‘Moq 4.0.10827’ が MvcHogeApp.Tests に正常に追加されました。

まずはControllerのテスト(HogeControllerTest.cs)を作成します

[TestClass]

public class HogeConrtollerTest

{

    // Moqを使ったテスト

    [TestMethod]

    public void TestMethod1()

    {

        // mockの作成

        var Mock = new Mock<IHogeWorkerService>();

        Mock.Setup(m => m.MakeHoge()).Returns(new HogeViewModels

        {

            HogeId = 1,

            HogeName = "HogeHoge"

        });

 

        // アクションメソッドの呼び出し

        var Target = new HogeController(Mock.Object);

        var Result = Target.Index() as ViewResult;

        var ViewModel = Result.ViewData.Model as HogeViewModels;

 

        // assert

        Assert.AreEqual(1, ViewModel.HogeId);

        Assert.AreEqual("HogeHoge", ViewModel.HogeName);

    }

}

ServiceWorkerクラスは各種ビジネスロジッククラス、データアクセスクラスなどを呼び出します。そのため、単純にServiceWorkerクラスのメソッドを呼び出してしまうと、それら各種ビジネスロジッククラス、データアクセスクラスの都合に引っ張られてしまいます。簡単な例としては単体テストを実行する環境にデータベースが作成されていて、テーブルが作成されていて、テストの条件に必要なデータが全部揃っている必要があります。また、呼び出し先のクラスメソッドが実装されていて、そのクラスにはバグがない状態でなければServiceWorkerクラスのテストができません。ServiceWorkerクラスのバグなのか、呼び出し先のクラスのバグなのか切り分けが必要になってしまいます。

そのため、呼び出し先クラスのmockを作成して、テストされるクラスにとって都合のいい(テスト条件に合った)固定の戻り値を返すように設定します。この場合はHogeWorkerService.MakeHogeメソッドの戻り値HogeViewModelsが固定値になるようにします。そしてこのモックをテスト対象クラスのコンストラクタの引数に指定します。これが、前回DIを採用した理由です。

ネット上にあふれている単体テストの記事を見ていると、単体テストができそうな気がするかもしれません。ただ、クラスの呼び出しは階層化されており単体テストをしたいクラス・メソッドから呼び出しているメソッドの戻り値を考慮しなければならず、これが現実の単体テストを難しくしている、ハードルを高くしている原因だと思います。なので(自分の身の回りでは)、単体テストは行われていません、UIを操作して手動でテストしたほうがはるかに簡単と考えられています。しかし、MockとDIを採用することで現実的な難しさまでハードルを下げることができると思います。

そして、WorkerSeriveの単体テストコードはこのようになります。

[TestClass]

public class HogeWorkerServiceTest

{

    [TestMethod]

    public void TestMethod1()

    {

        // mockの作成

        var Mock = new Mock<IHogeDao>();

        Mock.Setup(m => m.GetHogeList()).Returns(

            new List<HogeModels>

            { new HogeModels { Id=1, HogeName="HogeHoge"}}

        );

 

        // メソッドの呼び出し

        var Target = new HogeWorkerService(Mock.Object);

        var Result = Target.MakeHoge();

 

        // assert

        Assert.AreEqual(1, Result.HogeId);

        Assert.AreEqual("HogeHoge", Result.HogeName);

    }

}

現実のクラスはMock作成時の戻り値設定はこんなに簡単には行かないでしょうが。それでも「単体テスト」といいつつ、階層的に呼び出しを行ってテストをすることに比べれははるかに簡単になると思います。

今回は単体テストをテーマに書きました。作成したソースはSkyDriveにアップしてあります。「MvcHogeApp_v2」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

次はUnityを使ったDependectyResolverについて書きたいですね。

// なんで単体テストクラスのテンプレートに

// using System.Collections.Generic;

// using System.Linq;

// が含まれていないんだろう?軽くはまりましたわ。単体テストクラスのテンプレートはかなりすっきりしたのに、ちょっと残念

Written by david9142

2012年7月14日 at 6:22 PM

カテゴリー: ASP.NET MVC

Tagged with ,

ASP.NET MVCのクラスの作り方を考えてみた(1)

leave a comment »

以前のエントリーで紹介した「プログラミングASP.NET MVC」を読んだこと、.NETラボ勉強会でMVVMの話を聞いたこともあって、ASP.NET MVCでどのようにクラスを作っていくのかを考えてみました。プロジェクトテンプレートにはControllerクラスしかありませんし、スキャフォールドで作成したコードはControllerが直接データアクセスクラスを呼び出しいているし。ネットには超単純なシナリオにしか(現実的にありえないような)対応出来ないコードだし。

ネットで公開されているようなコードはわかりやすく・単純化するために仕方がないと思います。確かに新機能の説明や「ASP.NET MCとは」という内容に200~300行書かれても読む気がなくなってしまいますから。しかし、patterns&practicesで公開されている「Project Silk」や「Project Liike」のコード、現実のアプリケーション開発のコードはそれらネット上のサンプルからの乖離(飛躍)が非常に大きく、サンプルと現実の溝を少しだけ埋めてみようかなと思った次第です。

一発で「こうだ」というコードが公開できるとは考えていないので、ブログを書きつつ、考えつつ、軌道修正していくので複数回のブログになると思います。あと、前もって断っておきますが書籍「プログラミング ASP.NET MVC」の内容の自分なりの理解内容を発言することになると思います。とくにオリジナリティはないと思います。

今回はControllerクラスの設計について考えてみました。具体的には、この3つのテーマです。

  • Controllerクラスには何を記述すべきか
  • クラス同士の依存性をいかにして弱くするか
  • MVCの「C」と「M」の境目はどこになるのか

Controllerクラスには何を記述すべきか

Controllerの責務はクライアントからHTTPリクエストを受け取って、HTTPレスポンスを返す(Viewを返す)ことです。それ以上でもそれ以下でもありません。建物の出入口に当たる部分になり、クライアントの都合に引っ張られる部分になります。そして、セッション管理などのWeb/HTTPに依存する処理は担当するものの、いわゆるビジネスロジックと呼ばれる部分はコントローラーには記述しません。その役目はModelの部分が担います。Modelはなるべくクライアントアーキテクチャーに依存しないように作成したほうが、汎用性/再利用性が増すため、Webというアーキテクチャーに依存する部分はControllerに記述すべきだと考えます。ViewはModelのことを知らないですし、ModelはViewのことを知らないわけですから、クライアントアーキテクチャーに依存する部分はControllerが担当するのは自然なことだと思います。

そしてControllerに対して1つのWorkerServiceと呼ばれるクラスを作成します。ControllerとWorkerServiceは1対1で紐付き、Controllerで受け取ったHTTPリクエストに対する処理を行います。Controllerから必ず1つのWorkerServiceを呼び出します。複数のControllerから共通のWorkerServiceを呼び出しても構いません。そして、WorkerServiceはコーディネーターとしての役割を担います、WorkerService自体にはいわゆるビジネスロジックは記載せずに、複数のビジネスロジッククラスを呼び出して処理を行います。そして処理結果をViewModelとしてControllerに返します。Controllerは自分が知っている1人のWorkerServiceに処理を委ねます、WorkerServiceは自分が知っている複数のビジネスロジッククラスを呼び出して、処理結果をViewModelとしてControllerに返します。ConrotollerはHTTPリクエストの受付、WorkerServiceはビジネスロジックの実行を受け付けます。

図にするとこうなります。

image

クラス同士の依存性をいかにして弱くするか

クラス同士の依存性を弱くすると何が嬉しいのか、何なんでしょうねぇ...一番のメリットはテストがしやすくなることです。コードを変更せずに依存するクラスを変更することができれば、Mockを使ったテストがやりやすくなります。それ以外のメリットは...すみませんよくわかりません。個人的な実装と実行の分離の現実界は、DI(Dependency Injection)の利用かなとおもいます。実装クラスにに対してインターフェースを用意し、コンストラクタで依存性を注入するやり方です(コンストラクタインジェクション)。

このやり方の最も現実的なところは、依存性の型情報をC#のコードとして記述できることです。DIコンテナとしてSearsarプロジェクトのS2Containerを利用したことがありますが、設定ファイルに文字列として型情報のマッピングを記載しています。個人的にはtypoまみれになるので設定ファイルの利用が嫌いです、マッピングを文字列ではなく型情報をとしてコードで記述できれば、インテリセンスが効きますしtypoをかなり防ぐことができます。設定ファイルにマッピング情報を記述してtypoでハマると悲惨ですよ...ハイ。なのでS2Cotainer.NETのQuillの考え方はすごく好きです。ASP.NET MVC+C#の考え方なら、設定ファイルでゴリゴリ書くよりもコードで書くほうが合うと思うんですよね。

あと、プロダクションコードではDI目的のインターフェースと実装クラスは1対1になるので同じファイルに書いてしまったほうがコードの見通しが良くなると思います。

Unityも確か設定ファイルにマッピン情報を記載したはずです。Project Silkのコードをしっかり読んでないとか、Unityについてほとんど調べてないです、すみません...

MVCの「C」と「M」の境目はどこになるのか

ControllerとServiceWorkerの話が出現すると、「C」と「M」の境目はどこなのか、ServiceWorkerは「C」なのか「M」なのかという話題になるかもしれません。個人的には

「(´・ω・`)知らんがな」

です。「C」と「M」って論理的な考え方なので、物理的なクラスがどちらに属するかを真剣に議論してもねぇ。論理的な考えに基づいてきちんとクラスの責務が決められていればいいと思うんですよ。敢えてどちらかと言えば「C」かと思います、ServiceWorker自体はビジネスロジッククラスの呼び出しを行なってViewModelを作っているだけなので、「C」なのかな、と。

そして出来上がったコードはこのようになりました

Controller

public class HogeController : Controller

{

    private IHogeWorkerService WorkerService;

 

    // 通常のコンストラクタ

    public HogeController()

    {

        WorkerService = new HogeWorkerService();

    }

 

    // DI(コンストラクタインジェクション)

    public HogeController(IHogeWorkerService workerService)

    {

        WorkerService = workerService;

    }

 

    // アクションメソッド

    public ActionResult Index()

    {

        // コントローラーはHTTPリクエストを受け取って

        // HTTPレスポンス(View)を返すのみ

        // Webに依存する部分(セッション管理など)のみを担当する

        // アクションフィルタでできることはアクションフィルタで済ませる

       

        // アプリケーションとしての処理はすべてWorkerServiceに委ねる

        // ViewModelの作成もWorkerServiceに任せる

        // 1つのアクションメソッドで1つのWorkerServiceの呼び出しを行う

 

        // コントローラーはこのようなすっきりとしたものになるはず

        var ViewModel = WorkerService.MakeHoge();

        return View(ViewModel);

    }

}

WorkerService

// DIのためのインターフェース、実装クラスと11なので同じファイルにしてしまってもいいと思う

public interface IHogeWorkerService

{

HogeViewModels MakeHoge();

}

 

// WorkerServiceクラス、コントローラーから処理を任される

// このクラスから各種ビジネスロジッククラスを呼び出して

// アプリケーションの仕様を実現する

public class HogeWorkerService : IHogeWorkerService

{

    private IHogeDao Dao;

 

    // 通常のコンストラクタ

    public HogeWorkerService()

    {

        Dao = new HogeDao();

    }

 

    // DI(コンストラクタインジェクション)コンストラクタ

    public HogeWorkerService(IHogeDao dao)

    {

        Dao = dao;

    }

 

    // コントローラーから呼び出されるメソッド

    public HogeViewModels MakeHoge()

    {

        // この例ではデータベースアクセスを行う処理だけを呼び出しているが

        // 現実はもっとたくさんのメソッド呼び出しを行うはず

        var Hoge = Dao.GetHogeList().First();

 

        // ViewModelの作成はこのクラスで担当する

        return new HogeViewModels

        {

        HogeId = Hoge.Id,

        HogeName = Hoge.HogeName

        };

    }

 }

Model(データアクセスクラスのみ)

// DIのためのインターフェース、実装クラスと11なので同じファイルにしてしまってもいいと思う

public interface IHogeDao

{

    IEnumerable<HogeModels> GetHogeList();

}

 

// データアクセスクラス 「XXXRepository」という名前にするのは違和感がある

// Models」ディレクトリでいいんだろうか...

public class HogeDao : IHogeDao

{

    public IEnumerable<HogeModels> GetHogeList()

    {

        using (var db = new MvcHogeAppContext())

        {

            return db.HogeModels.ToList();

        }

    }

}

作成したソース(ソリューション一式)はSkyDriveにアップしてあります、「MvcHogeApp」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

Written by david9142

2012年7月13日 at 10:35 AM

カテゴリー: ASP.NET MVC

Tagged with ,

「プログラミングASP.NET MVC」読みました

with one comment

4月のWindows Developer Daysで買った「プログラミングASP.NET MVC」をやっと読み終えました。自分自身に対して「今さらかよ」と突っ込みたくなりますが…素晴らしい本でした。

IMG_20120425_002027

本書の対象はASP.NET MVCの開発経験がある、または、サンプルソースを読んだことがあり、このフレームワークを利用してどのようにプログラムを記述するかを理解している人、さらに、包括的に、深くASP.NET MVCについて理解したい人だと思います。

「ASP.NET MVCとは」や「そもそもWebFormとは何が違うの?」についてはほぼ触れられていないため、初心者ではなく中級者がより理解を深めるために読む内容になっています。自分も個人的に簡単なアプリを作成したことがあり、(ちょっとサバを読むと)自称中級者なので、この本の対象としてはぴったりだったかもしれません。

本書の中で一貫して書かれていることは、ASP.NET MVCの柔軟性です。素の機能をだけを使用しても、これまでのASP.NET以上にアプリケーションが作りやすくなっていますが、それに加えてASP.NET MVCはほぼすべての要素が使いやすくカスタマイズすることができます。ビューエンジン、ルーティング、モデルバインダー、HTMLヘルパー、属性といったありとあらゆる要素に対して、カスタムモジュールを追加・標準モジュールを置き換えることができます。「第1部 ASP.NET MVCの基礎」では、標準機能の説明を行ったあとにあるシナリオにもとづいてカスタム機能をどのように実装するかについて触れています。

個人的に読んでいて興味を持ったのは、第2部(7章、8章)のコントローラーの設計の部分についてです。MVCの「C」部分にはどんな処理を書くべきか、その延長上にMVCの「M」とは何か、について記載があります。自分のようなレベルの低いエンジニアの書くプログラムは(しかもサンデープログラマーなので書く前にちゃんと設計しない)コントローラーに処理(ロジック)を記載してしまいます、で、Mの部分はデータアクセスのみ。ネット上に大量にあふれているサンプルコードもこのように書かれているケースが多いですが、サンプルのような超シンプルなシナリオだから破綻しないだけで、通常のシナリオではコードが破綻します。自分の経験上、比較的簡易なシナリオでもコントローラーに処理が満載になってしまって我に返ることがあります。コントローラーはHTTPリクエストの受付と、レスポンスの返却を行います、モデルバインダ経由で受け取ったViewModelをどう扱うかは、Modelに任せます。それがWebアプリケーションのMVCのパターンです。(たぶん)あまり長く書くとボロが出るので、この辺に興味がある方はこの本の7章、8章を読むといいと思います。キーワードとしては「ぜい肉のないコントローラー」「iPODDパターン」「ServiceLocatorモデル」でしょうか。

この本は現実にはありえないような超シンプルなシナリオではなく、より現実に即したシナリオにも適用できるべく記述されているため、読んだ内容が次々に頭に入ってくるというわけではありません。もともと中級者以上向けの内容に加えて、現実にありあり得るパターンに対応しようとすると、自分のCPU(脳みそ)では知恵熱が出てしまいます。わかったような…わからないような…中途半端な気分になります。

そして、ふとこんなつぶやきをしてしまいました。

image

image

すると意外に反応があって、この本の内容、もしくは中級者以上向けのフォローの場って需要があるんだなと感じました。読書会は定期的に複数回開催されるもののようなので難しいですが、自分も中級者以上向けの勉強会というかイベントには参加してみたいです。

ということでこんな内容を聞いてみたいと妄想してみました。他の方のブログやプレゼンテーションを引用させていただいています、問題がある場合はTwitter(@david9142)または、ブログのコメントで連絡ください。

タイトルは

「ぼく/わたしのかんがえたさいきょうのえーえすぴーどっとねっとえむぶいしー」

初心者は完全に置き去り、中級者に対してLevel5の方たちが「オラオラ!! オレのテールに食らいついてこい!!!」と煽る場にしたいですね。そんなドMなLevel2,3なエンジニアが集まる場にしたいです。個人的に聞いてみたい話は以下のブログ・プレゼンテーションの内容です、しかも、上級者向けにカスタマイズされたものを。

MVCの「M」と「C」とは

年末だからこそ ASP.NET MVC のモデルの作り方について考えてみる (@shibayanさん)

ぜい肉のないコントローラ をめざそう! (@miso_soup3さん)

Patterns&Practice

Project Liike: モダン モバイル Web アプリ開発ガイダンス&サンプルコード公開です! (@chack411さん)

モダン ブラウザのためのクライアント サイド Web 開発ガイダンス ~ Project Silk リリース (@chack411さん)

単体テスト

基礎から見直す ASP.NET MVC の単体テスト自動化方法 (@normalian さん)

オープンソース

ASP.NET Open Sourcing Discussion with Scott Hanselman (@shanselman)

 

自分の知り得る情報は限られたものなので、ASP.NET MVC界はもっともっと有名な方がいらっしゃるのかもしれません。自分の言いたかったことは、この本をきっかけに

「わたしの戦闘力は530000です」

という人達(MS社員も含む)の全力のプレゼンテーションを聞いてみたいなぁ、という個人的な好奇心が生まれました。こういう場を設けるためには何をやったらいいんでしょうか?「自分はこんな内容を聞いてみたい」という意見が色々とあると思います。Twitterは苦手なので、ブログで会話しませんか?「ぼく/わたしのかんがえたさいきょうのえーえすぴーどっとねっとえむぶいしー」というタイトルで、このブログエントリー・プレゼンテーションの全力のを聞いてみたい、という内容をブログで書きましょう。で、書いたら #aspnetjp のハッシュタグをつけて、ブログ書きましたとつぶやいてみるのはどうでしょうか。きっと誰かが…こういう場を設けてくれるはず…何とかしてこういう場を設けたいです、はい、本気です。

Written by david9142

2012年7月5日 at 12:40 AM

「ASP.NET Open Sourcing Discussion with Scott Hanselman」をやっと観ました

leave a comment »

ずっとまえから観ようと思ってRead It Later(Pocket)に登録しておいた動画「ASP.NET Open Sourcing Discussion with Scott Hanselman」をやっと観ました。.NETラボ6月勉強会でこの内容に近いことを話す機会をいただいたのでやっと踏ん切りがつきました。

ASP.NET Open Sourcing Discussion with Scott Hanselman

ASP.NET MVC4のオープンソース化について基本は以下のブログに書かれていることが中心です。

ScottGu’s Blog: 
ASP.NET MVC, Web API, Razor and Open Source

Scott Hanselman’s Blog: 
ASP.NET MVC 4, ASP.NET Web API and ASP.NET Web Pages v2 (Razor) now all open source with contributions

ただ、ブログに書かれていない興味深い内容についてもしゃべっています。しゃべっている内容を全部まとめるにはガッツが足りないので、個人的に興味を持った部分を抜粋してメモを残しておきます。(英語のスキルには自信がないので、一部内容が間違っているかもしれません)

  • ソースを公開するだけのオープンソース化ではない、ASP.NET MVCはオープンな開発を行う
  • Folks, PullRequestができるようになったし、ユーザーとディスカッションを行うことができる
  • 誰でもコミットできるわけではない、PullRequestの内容をみてASP.NET MVC開発チームで判断する
  • PullRequestに対しては内容を見てディスカッションを行い、取り込むべきと判断したらコミットする
  • ASP.NET MVC開発チームは内部のTFSではなく、パブリックなGitリポジトリにコミットする
  • フィードバックやバグフィックスのリリースサイクルをもっと短くしたい
  • CodePlexがGitをサポートした、これでTFS/Subversion/Mercurial/Gitに対応したことになる
  • CodePlexはTFSのチームと密接に関わっている?

ASP.NET MVCはChromeやFireFoxのように短い周期でどんどんリリースされていくのかもしれません。しかも、WebPIやダウンロードセンターで入手するのではなく、Nugetで配布される気が。4.0.1、4.0.2、4.1.0とか登場すると胸がアツくなりますね、ただ、どのバージョンを使うかでいろいろと問題になる気も。

Channel9ってしゃべってる内容を英語でいいから字幕をつけてくれないかな…デモなしで淡々としゃべっている動画は英語圏じゃない人には辛すぎる。ただの睡眠導入動画になってしまいます。(興味があってみてるんだから寝るな、というツッコミもありますが)

Written by david9142

2012年6月25日 at 2:07 AM

カテゴリー: ASP.NET MVC

Tagged with ,

【日本語訳】ASP.NET MVC4 Beta Relaese Note(3)

leave a comment »

日本時間の2/17に ASP.NET MVC4 Betaのリリースノートが公開されています(こちら)。もちろん英語なのでざっくり日本語訳したいと思います。長くなるので3回に分けたいと思います。

  1. Installation Note ~ Upgrading an ASP.NET MVC3 Project to ASP.NET MVC4
  2. New Features in ASP.NET MVC4 Beta(Azure SDK まで)
  3. New Features in ASP.NET MVC4 Beta(Known Issures and Breaking Changes)

※この文章は個人が勝手に訳した文章であり、正しさを保証するものではありません。違和感を感じた場合は、必ず原文に当たってください。新機能の部分は未検証なので一部日本語訳に自信がありません。

今回はNew Features in ASP.NET MVC4 Beta(Known Issures and Breaking Changes)です。

Known Issures and Breaking Changes(既知の問題と重大な変更)

  • Visual Basic プロジェクトでArea内でControllerの追加を行うと、間違った名前空間のコードが生成される。Visual Basicを使用しているASP.NET MVCプロジェクトでArea内にControllerの追加を行うと、アイテムテンプレートが間違った名前空間をコントロラーに生成してしまいます。コントローラーのアクションメソッドを実行すると ”file not found” エラーが発生します。

生成された名前空間は、ルート以降の名前空間が抜けてしまいます。例として、RootNamespace.Areas.AreaName.Controllers という名前空間が生成されるべきところ、Rootnamespaceという名前空間が生成されてしまいます。

  • Ravor View Engineに関する重大な変更。Razorのパーサー書き換えの一部として、以下の型が System.Web.Mvc.Razor から削除されました。
    • ModelSpan
    • MvcVBRazorCodeGenerator
    • MvcCShartRazorCodeGenerator
    • MvcVBRazorCodeParser

以下のメソッドも削除されています。

    • MvcCSharpRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)
    • MvcWebPageRazorHost.DecorateCodeGenerator(System.Web.Razor.Generator.RazorCodeGenerator)
    • MvcVBRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)
  • ASP.NET MVC4アプリケーションの bin ディレクトリに WebMatrix.WebData.dll が含まれていると、form認証URLが上書きされてしまう。アプリケーションにアセンブリ WebMatrix.WebData.dll を追加すると、(例として、配置可能な依存関係の追加ダイアログで「ASP.NET WebPages with Razor Syntax」を選択する)ログイン認証のURLをASP.NET MVC Account Controllerの /account/login から /account/logon へオーバーライドしてしまいます。この事象を回避し、web.configのauthenticationセクションで定義されているURLを使用するためには、appSettingに「PreserveLoginUrl」を追加して値を「true」に設定します。

  <appSettings>

    <add key="PreserveLoginUrl" value="true" />

  </appSettings>

  • ASP.NET MVC4とVisual Studio 2010/Visual Web Developer 2010を同時にインストールすると、Nuget package managerのインストールに失敗する。ASP.NET MVC4のインストールは、Visual Studioのインストール後に実行する必要があります。
  • 必要なソフトウェアがアンインストールされた状態では、ASP.NET MVC4のアンインストールが失敗する。ASP.NET MVC4をアンインストールするためには、Visual Studioよりも先にアンインストールする必要があります。
  • デフォルトのWeb APIプロジェクトを実行すると、ルーティングの追加に存在しないメソッド「RegistarApis」を使うという、ユーザーに間違った手順を示してしまう。ルーティングの追加ASP.NETルーティングテーブルを使用して RegisterRoues で追加しなければなりません。
  • ASP.NET MVC4 Betaをインストールすると、ASP.NET MVC3 RTMアプリケーションが壊れてしまう。RTMリリースで作成されたアプリケーションは(ASP.NET MVC3 Tools Updateは対象ではありません)、ASP.NET MVC4と並行して実行するために以下の変更が必要です。以下の変更を行わずないとプロジェクトはビルドエラーになります。

1.プロジェクトのルートにある Web.configファイルに、新規に<appSettings>エントリーを追加してkeyに「WebPages:Version」、valueに「1.0.0.0」を指定します。

    <appSettings>

      <add key="webpages:Version" value="1.0.0.0"/>

      <add key="ClientValidationEnabled" value="true"/>

      <add key="UnobtrusiveJavaScriptEnabled" value="true"/>

    </appSettings>

2.ソリューションエクスプローラーから、プロジェクト名を右クリックして「プロジェクトのアンロード」を実行します。そして、再度右クリックし、「編集 [プロジェクト名].csproj」を選択します。

3.以下の参照アセンブリ部分へ移動します。

<Reference Include="System.Web.WebPages"/>

<Reference Include="System.Web.Helpers" />

以下のように置き換えます。

<Reference Include="System.Web.WebPages, Version=1.0.0.0,

Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL "/>

<Reference Include="System.Web.Helpers, Version=1.0.0.0,

Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

4.変更を保存して、プロジェクトファイル(.csproj)を閉じます。プロジェクトを右クリックして、「プロジェクトの再ロード」を選択します。

Written by david9142

2012年2月18日 at 11:10 PM

カテゴリー: ASP.NET MVC

Tagged with ,