Reinforced.Typings-TypeScriptチップの自動生成のためのライブラリであり、

TypeScriptとASP.NET MVCが好きな人向けに、小さくても便利なライブラリを作成しました。 私はそれについて話をしたいと思います-おそらく前述の技術の組み合わせの開発者（そしておそらくチーム全体）にそれは人生をはるかに楽にするでしょう。 完全なドキュメントを英語で書く時間はありません。 一般的に、感覚、感覚、配置で意識的にそれに取り組む必要があります。 したがって、私はHabrahabrについての記事を書くことにしました。そして、今、私は簡単なレビューを行い、このことを行うことができる魔法を示します。 どういたしまして

歌詞の紹介

一般に、バックエンドとフロントエンドを.NETスタックに緊密に統合するというアイデアに長い間強く期待しており、その結果、JavaScriptでC＃からトランスレーター全体を作成しようとすることさえありました。 結果が得られなかったとは言いません-私の翻訳者はいくつかのC＃クラスをJavaScriptに正常に変換し、最終的に中断されたアニメーションとアーキテクチャを再考しました。 いつか彼に戻ってきます。 必須です。



しかし、それにもかかわらず、プロジェクトの現在のタスクを何らかの形で解決する必要がありました。 そして、ほとんどすべてのWebプロジェクトでの現在のタスクは、一般的に非常に典型的なものであり、退屈という言葉を恐れていません。 今、私はあなたの許可を得て、Automapperの使用、IoCコンテナの収集、EF / NH /何かを使用したデータベースでのざわめきなど、あらゆる種類の複雑なものから抽象化し、フロントエンドに近づきます。 そのため、バックエンドとフロントエンドの接合部には、多くの退屈で典型的なタスク（皮肉）もあります。 具体的には、データを含むJSONのサーバーへのリクエスト、その表示、およびAJAXによるさまざまな操作のパフォーマンス。 Reinforced.Typings（これはまさに私のちょっとした助けと呼んでいます）は、この暗黒の王国にちょっとした楽しさ、典型的なタスクの簡素化、定型コードの削除、そしてもう少しの一貫性をもたらします。



MicrosoftがTypeScriptを提供して以来、クライアント側のJavaScriptの記述はずっと快適になりました。 TypeScriptは、それが欠けていた場所にタイピングとコンパイルの感覚をもたらしました。 まだ試していない場合は、必ず試してください（これは広告ではありません）。 もちろん、特定のプロジェクトのTypeScriptの「存在するかしないか」の問題について多くのことを議論することはできますが、議論を省略して「-身体に近づきましょう！-Guy de Maupassantが言ったように」に進みましょう。

実用例

そのため、シンプルだがかなり一般的な例を考えてみましょう。サーバーにリクエストを行い、注文に関する情報を取得して、ブラウザのページに何らかの方法で表示する必要があります。



この問題を解決するために通常何をしますか？ そうだね。 POCO注文モデルと、JSONでラップされたインスタンスを返すコントローラーメソッドを実行します。 ここに、私たちのヒーローがいます（ご存じのとおり、余分なコードを削除してスペースを節約します）：







ここではすべてが多かれ少なかれ明確であり、コメントは不要だと思います。 クライアントに切り替えましょう。 非常に明確にするために、ajaxリクエストにjQueryを使用しますが、必要に応じてjQueryを独自のものに置き換えることができます。 前と同じように、冗長なグルーコードを省略し、ビュー、TypeScriptファイルを作成し、ページに接続し、NuGetからjQueryをインストールします。これは私なしで実行できます。 私はその本質を強調します（このTypeScriptコードをもう一度思い出します）：





ここですべてが順調です。 基本的にJavaScriptを除いて、この構造は同じです。 サーバーからJSONの一部を取得します。このオブジェクトでは、ClientName、Address、その他のフィールドがあるという事実に依存して、divに表示します。 あまり安定していません。 不幸なジュニアがViewModelおよびC＃コードからClientNameフィールドを削除した場合（またはジュニアリファクタリングのために名前を変更した場合）、そのような構成が使用されるフロントエンド上のすべての場所が起爆装置になり、待機しますテスターの到着。 さて、またはエンドユーザー、そして誰かがとても幸運になります。 どうする？ 答えは明らかです。TypeScriptを使用しているため、この特定のViewModelのチップを記述して、次のようにコードを書き換えることができます。

 private handleResponse(data: IOrderViewModel) { var text = `${data.ClientName}, ${data.Address} (${data.ItemName}, ${data.Quantity})`; $('#divInfo').text(text); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、今ではやや快適になりました-宣言されていないフィールドへのアクセスに対して保険をかけました。 しかし、フィールドの名前を個人的に変更した後輩の状況では、私は平和に眠ることができません。 はい、すべてのViewModelのタイピングを記述します...手で...夜に...そして、プロジェクトに何百人もいる場合は？ そしてもし何千？ 率直に言って、見通しはまあまあです。



これがReinforced.Typingsの出番であり、問​​題の解決策は根本的に異なる方法で始まります。 そこで、PMコンソールを開き（まあ、または誰にとっても便利です-グラフィカルインターフェイスを使用してこれを行うことができます）、設定します。

 PM > Install-Package Reinforced.Typings
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクトのルートに新しいファイルReinforced.Typings.settings.xmlがあります。 それは十分に詳細に文書化されており、ここに記載されているすべてを書き直すことは重要ではありません（もちろん、聴衆の誰かが英語でうまくやっていない限り）。 パラメーターを1つだけ変更します。これは、生成されたチップが置かれるファイルへのパスです。 私のプロジェクトでは、次のようになっています。

  <RtTargetFile>$(ProjectDir)Scripts\app\Server.ts</RtTargetFile>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、modelkaのコードに移動し、Reinforced.Typings.Attributesとmodelkaのクラス自体の上の[TsInterface]属性を使用して、2行のコードのみを追加します。 このようなもの：

 using Reinforced.Typings.Attributes; [TsInterface] public class OrderViewModel { //        }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、プロジェクトを再構築（再構築）し、Server.tsの構成に従って生成されたScripts \ app \に手動で追加します。 指定されたフォルダーに既にあります-単にプロジェクトに追加されていません。 Server.tsを開いて、その中身を見てみましょう。





見えますか？ 素晴らしい。 プロジェクト全体のViewModelのタイプを作成するタスクは、それほど怖くはないようです。 はい、ViewModelの削除と名前変更は悲劇ではなくなりました。次にプロジェクトをビルドすると、チップが再生成され、チップに関連付けられているTypeScriptコードが収集を停止します。



主な可能性のこの実用的なデモンストレーションは、次の記事でより複雑な例を残し、劇的な結論に進むことで完了すると思います。

劇的な結論とそれについて少し

Reinforced.Typingsは実際には多くのことをサポートしています。 以下に短いリストを示します。

• 自動的に関連付けられたデリゲート、IEnumerableおよびIDictionaryの子孫（プロパティとして使用する場合）
• 列挙型とクラスの太字化（メソッドの本体をTypeScriptに自動的に変換することはできませんが、自分で行うことはできます-以下で詳細を説明します）
• 複合型を持つ型-Reinforced.Typingsは、クラスで別のエクスポートされた型を使用していることを理解し、その場所で使用される型の完全修飾名を自動的に配置します。 それ以外の場合は、任意の
• 適切な構成パラメーターを使用して、生成されたコードを異なるファイル（クラスごとのファイル）に分散させることができます。
• アセンブリ属性[TsReference]を使用して、生成されたファイルに/// <reference ...>を追加できます。 クラスごとのファイルの場合、参照は自動的に隣接ファイルに追加されます
• 通常の.tsコードの代わりに.d.tsファイルを生成できます（構文にいくつかの違いがあります）
• ケーキのチェリー-各属性にはCodeGeneratorTypeプロパティがあり、Reinforced.Typings.Generators.ITsCodeGenerator <>（オプションとして、既存のジェネレーターから継承）から継承タイプを指定し、任意のテンプレートTypeScriptコードを独自に生成できます。 。 このようにして、サーバー側のViewModelコードから直接、ノックアウトのViewModelの自動作成に進むことができます。 現在の作業場所のプロジェクトでは、コントローラーアクションのコードジェネレーターをオーバーロードし、指定されたパラメーターで対応するコントローラーメソッドを呼び出して、多くのメソッドのjs番目のグルーコードを生成しました。 このようなメソッドはq-shny promiseを返します（単にQ.jsが大好きだからです）。 これについては次の投稿で説明します

マイナスの点： Reinforced.Typingsはクラスメソッドのボディを自動的に生成できません -Reflection を介して機能します。 まあ、サーバーエンティティは正しいTypeScriptコードを提示するが、既に生成されたコードにセマンティックエラーが含まれる（フィールドが削除されるなど）状況でのいくつかの問題に注意したいです。 TypeScriptアセンブリの機能（プロジェクト全体で最初のアセンブリ）により、プロジェクトを再構築し、エラーを手動で修正するまでエラーを修正する正しいチップを生成することはできません。 しかし、私はそれに取り組んでいます。 MSBuildの魔法は驚異的です。



前述のように、プロジェクトにはまだドキュメントがほとんどありません（この記事ですが、githubのreadme）。 しかし！ XMLDOCは非常に詳細であり、設定ファイルにコメントが付けられています。 ですから、初めてで十分だと思います。 そして、私はすでに学生のテクニカルライターを募集しており、通常のReinforced.Typingsベストプラクティスブックをwiki形式のドキュメントで作成します。



今日は以上です。 ご質問がある場合は、コメントを記入してください。 答えようとします。



プロジェクトへの参照：

強化：Githubのタイピング

強化されたNuGetのタイピング

検討された例の完全なコード



UPD ： Reinforced.Typingsに関する2番目の記事で、詳細を説明しています。