CodeZineに面白そうなタイトルの記事を見つけました。
一通り読んだのですが、用語の使い方というか内容がちょっとしっくりこない所があったので、しっくりこない所を、もう一度読みながら書きだしてみようと思います。因みに、テーマとしてはとても楽しみな分野なので、連載の続きは楽しみにしてます！！！！
とりあえず、引用と違和感を感じる理由を順番に書いていってみようと思います。
「はじめに」の部分
また、社内だけでなくインターネットからもアクセスしたい情報を社内サーバーから配信するためには、セキュリティや運用に関わるコストも肥大化するため、機密度の低い情報をAzureに分離して、インターネットからアクセスできるようにするといったデータポータビリティが設計されることがあります。
「データポータビリティが設計されることがあります。」が何となく普段言わない言い回しなような気がしたので意味を調べてみました。Blogの記事で言われてる定義になりますが、ざっと個人的な認識は以下のような感じです。
ソーシャルネットの焦点、データポータビリティから抜粋
データポータビリティというのは、ソーシャルメディアのユーザーが自らの交友関係や自分の個人情報などを自身で管理し、さまざまなソーシャルメディアで共有できるようにしようという概念である。
前の文章が「また、社内だけでなくインターネットからもアクセスしたい情報を社内サーバから配信するためには」なので、それに対して「データポータビリティが設計されることがあります。」
「〜するためには〜されることがあります。」言い回し。何となく日本語としてあまり言わない言い回しな気がする。言い回しに違和感を感じました。
「本連載のゴール」の部分
本連載では、Azure特有のアプリケーションロジックをSilverlightに任せる方法を紹介することで、アプリケーションレイヤーの分割を解説していきます。
はじめにの部分でAzure特有のロジックをアプリケーションロジックとして定義しているのでAzure特有のアプリケーションロジックと言われると「Azure特有のAzure特有のアプリケーションロジック」と言っているようで気になりました。
業務ロジックに注力できるようにアプリケーションロジックの実装工数を軽減するためには、業務ロジックとアプリケーションロジックを分割する必要があります。この分割は論理的に行えばいいのですが、構築や保守、運用工数の軽減のひとつの方法として、これらを物理的に分割することは有用です。
前半の文には同意なのですが、後半の文が解せません。何故論理的なレイヤ分割を物理的に分割することで、構築や保守、運用工数の軽減につながるのかがわかりません。物理サーバが増えるぶん、構築や保守、運用工数が増えるような気がします。それともAzureを見据えて、サーバが増えてもAzureだから無問題といってるのでしょうか？でもSilverlightで作るという事は、クライアントサイドとサーバ（Azure）側という感じになるので運用の手間が特別増えるというわけではないですね。でも、軽減される理由がわかりません。私の認識不足なら教えてほしいです。
Microsoftの技術であるWCF RIA ServicesやEntity Framework、ASP.NET Dynamic Data等は、アプリケーションの複数のレイヤーを飛び越えて、クライアントからデータ層に直接アクセスする技術です。
飛び越えてないと思います。Dynamic Dataは、画面等がデータに応じて自動で作成されるので直接アクセスというイメージが少しはしっくりきますが、Entity Frameworkは全然違うと思います。ただのデータアクセスの１テクノロジだという認識です。
「今回のSilverlightの役割」の部分について
データベース連携を行うことの多い業務アプリケーションでは、データアクセスレイヤーから正規化されたリレーショナルデータベースなどに接続して、取得したデータを業務ロジックで扱いやすいようにオブジェクトとしてクラス化します。
オブジェクトとしてクラス化するという表現は、あまり聞いたことがないです。
検索件数は2610000件ひっかかってますが、そのものの文章はひっかかってきません。
さらにビジネスレイヤーで加工して、概念モデルというアプリケーションの画面に近い形のデータにします。これをインピーダンスミスマッチの解消と言います。
インピーダンスミスマッチの解消は、O/Rマッピングのようなリレーショナルデータベースの世界とオブジェクト指向の世界の間を埋めるという説明では良く見ますが、このようなクラスからクラスの変更で使用する例は初めて見ました。でも、データモデルから画面に向いたデータのギャップを埋めるという意味ではあってるのかな・・・？
「射影」の部分について
この軽減されたコーディング作業というのは、単に自動的にプログラムコードを生成するという利点の他に、サーバーとクライアントで同じ形のクラスを持つことで、クライアントアプリケーションは、クライアントにあるオブジェクトを操作するというシンプルなプログラミングが可能になります。これは「プロジェクション（以降、射影）」という技術です。
プロジェクション（射影）の使い方に違和感を感じます。一般的な使われ方は以下のようなものだと思っているのですが、ここではメタデータからのコードの自動生成を射影と言ってるように感じます。
・選択(selection) → 行の抽出 ・射影(projection) → 指定した列を抽出 ・結合(join) → 複数の表を結合して1つの表にする
この技術はWCF Serviceでは一般的な技術で
細かいですが、日本語で表記されるときは「WCFサービス」と記載されることが多いと思います。
「WCF RIA Servicesの構築作業の特徴」の部分
WCF RIA Servicesは、WCF ServiceにADO.NET Data Serviceを追加したWCF Data Serviceの後継技術です。
これは違います。WCFというテクノロジをベースに作成されたWCF Data ServicesとWCF RIA Servicesという別のテクノロジと言う認識です。
この部分は射影という単語が違和感がありすぎるのと、全体的に何を言ってるのかよくわかりません。
「まとめ」の部分
「図17 サンプルアプリケーションのレイヤー構成」
DomainDataSourceとかObjectContextはモデルで、ビューモデルではないような・・・。
アプリケーションのレイヤー設計をする際に、物理的な配置によるレイヤーの分離は、最もメンテナンスの良い分離です。
物理的な配置の分離が、最もメンテナンスの良い分離というところが解せぬ！
