2016-12-01 4 views
2

Also arbeite ich an diesem ASP.NET (.NET 4.6, VS2015), die alle Geschäftslogik in C# geschrieben hat. Aber da es nicht nur ein Präsentations-Web ist, wird es auch eine Menge Logik für den Kunden geben. Also nahm ich TypScript, da es wie ein großartiges Werkzeug aussah, das mir helfen würde, meinen clientseitigen Code mit einem Stil zu organisieren, den ich von C# gewohnt bin.Strukturierung von TypeScript-Dateien und Code in ASP.NET-Projekt

Da ich tiefer und tiefer tauche, sehe ich, dass TypeScript nichts mit C# zu tun hat. Alles hängt mit einem einzelnen Problem zusammen:

TypeScript unterstützt keine einfache Klasse-pro-Datei- (oder Schnittstellen-pro-Datei usw.) -Regel, wo Sie einfach mehrere Klassen (Schnittstellen ..) in eine andere Datei aufnehmen könnten .

Dies wäre wirklich nützlich, da ich meine ViewModel-Klassen und Initialisierungsskripte für jede Seite definieren möchte, wo ich all diese Modelle und Utils verwenden würde.

Personaly, fand ich zwei "Lösungen"

A: Halten Klasse-per-Datei Regel und wickeln jeweils in einem Namespace wie folgt aus:

// Analogy to c# using 
import utils = App.Code.Utils; 

namespace App.Code { 
    export class ZipCodeValidator { 

     public zipCode: string; 

     public validate(): boolean { 
      // I can use class from another 
      let stringValidator: utils.StringValidator = new utils.StringValidator(); 

      // TODO validation 
      return true; 
     } 
    } 
} 

Diese Lösung, die ich von Anfang nahm, und ich war sehr glücklich damit. Bis ich herausfand, dass manchmal die Reihenfolge der kompilierten Dateien falsch ist. Ja, ich kann manuell andere Dateien referenzieren (oder _references.ts verwenden), aber für mich ist es so, als würde ich einige Jahre zurückgehen. Ich werde Hunderte von Dateien haben (dank meiner Klasse-pro-Datei-Regel).

Auch "sie sagen" Ich kann js-Dateien von Namespaces generieren, was auch ein großer Vorteil ist, so kann ich Dateien general.js, app.js und admin.js erstellen (Sie wissen, was wo verwendet werden würde).

B: Zweite Lösung ist es, Module "richtig" zu verwenden. Wie ich es verstehen funktionieren, kann ich es so schreiben:

import { StringValidator } from "./Utils/StringValidator"; 

export default class ZipCodeValidator { 
    public zipCode: string; 

    public validate(): boolean { 
     // I can use class from another 
     let stringValidator: StringValidator = new StringValidator(); 

     // TODO validation 
     return true; 
    } 
} 

Aber das bedeutet, dass ich jede einzelne Klasse manualy importieren müssen. Trotz der Tatsache, dass intellisense bei diesem Ansatz nicht richtig funktioniert, muss ich, wenn ich das Schlüsselwort "default" weglasse, auch jede Klasse manuell angeben. Ich weiß auch nicht über irgendeine Möglichkeit, Quellen in verschiedene js-Dateien basierend auf Verzeichnis zu trennen.

OK, Sie können sagen, dass ich TypeScript missverstanden habe. Es geht nur um Module, oder? Aber ich werde nicht mit "Sie müssen alle Ihre Klassen in einem Modul definieren" zufrieden sein. Das ist einfach nicht richtig. Ich könnte dann mit JavaScript bleiben.

PROBLEM mit A: Ich muss manuell alle Dateien verfolgen und ihre korrekte Reihenfolge beibehalten.

PROBLEM mit B: Ich muss alle Klassen nach Klassen importieren. Lösung wäre, wenn ich sowas machen könnte wie

Aber soweit ich verstehe, ist das nicht möglich.

Zusammenfassung

Könnten Sie mir bitte einen Push zu dem richtigen Weg geben? Irgendein Werkzeug, vielleicht ein Plugin oder irgendetwas? Ich mag TypeScript und möchte es verwenden. Ich weigere mich einfach, in diesen Tagen manuelle Arbeit zu machen. Ich hoffe, dass diese Frage anderen Leuten wie mir helfen wird.

Dank

+0

Ein nettes Update. Ich habe die TypeScript-Erweiterung von VS (wurde nicht in Updates aufgelistet) in TypeScript 2.0.6 (ab 1.8) aktualisiert und es sieht so aus, als würde Visual Studio selbst die Reihenfolge der kompilierten Dateien verfolgen. Die Lösung A funktioniert jetzt viel besser. Jetzt bekomme ich einen richtigen Fehler, wenn etwas nicht in der richtigen Reihenfolge ist. Doppelklick auf den Fehler bringt mich zu dem Ort, wo dies passiert. Trotzdem muss ich herausfinden, welche ts-Datei/Klasse berücksichtigt wird, und sie manuell zu _references.ts hinzufügen. –

Antwort

2

So wie ich es tun, ist Ansatz B und Verwendung Module zu verwenden. Ich sammle dann alle gängigen Module in einem Wrapper-Modul, wo ich sie für den einfachen Import in andere Module re-export.

Ein Beispiel:

AllUtils.ts

export * from './UtilClass1'; 
export * from './UtilClass2'; 
export { UtilClass3 as SomethingElse } from './UtilClass3'; 

Diese Anwendung ermöglicht eine einzige Import-Anweisung zu verwenden, um alle Ihre Klassen wie folgt zu importieren:

import * as utils from './AllUtils'; 

let myUtil = new utils.UtilClass1(); 

Intellisense funktioniert für mich in VS2015 mit diesem Ansatz. Zusätzlicher Vorteil davon ist, dass Sie bestimmte Klassen im Re-Export auslassen oder umbenennen können. Sie müssen sie immer noch einzeln in die Wrapper-Datei einfügen, dies muss jedoch nur einmal durchgeführt werden.

+1

Hallo, danke für die Antwort. Ich werde Ihre Antwort definitiv verbessern, da sie B einige Vorteile bringt, aber ich denke nicht, dass dies als akzeptierte Antwort betrachtet werden kann. Wie Sie gesagt haben, muss ich es noch manuell zu einer Datei hinzufügen. Außerdem sehe ich keinen Vorteil darin, bestimmte Klassen weglassen oder umbenennen zu können. Tatsächlich denke ich, dass es das Gegenteil ist. Wenn jeder im Dev-Team eine einzelne Klasse mit ihrem eigenen Namen umbenennt, kann dies nur zu vielen "wtf-Momenten" führen. Vielleicht funktioniert das gut in Node.js, aber im ASP.NET-Projekt sollten wir alle konsistente Klassen/Schnittstellen-Namen haben wollen. Wie auch immer, danke nochmal. Martin –

Verwandte Themen