Business-Web-App in .NET - welche Technologie zu wählen?

8

Ich arbeite an der Portierung einer Winforms-Anwendung im Web. Dies ist eine Geschäftsanwendung, aber die Kontrolle über den Browser des Endbenutzers ist nicht verfügbar. Meistens wird jeder IE, Chrome, FireFox auf Desktops und Safari auf IPads verwenden.

Die Anwendung verwendet stark ListViews, TreeViews, Grids, Diagramme und hat eine allgemeine "Dock-style" -Schnittstelle (Navigationsleiste auf der linken Seite, Detailseiten auf der rechten Seite und Registerkarten - ähnlich der Visual Studio UI) ). Benötigen kein SEO / HTML-freundliches Framework, da die App vor Suchmaschinen versteckt ist.

Auf der Suche nach Empfehlungen zu Web-Technologie. Benötigen entweder native oder Drittanbieterunterstützung für ListViews, TreeViews, Raster, Diagramme und Docking-UI. Schnelligkeit auf den Markt und Einfachheit sind sehr wichtig. / Hass / herumschrauben mit Javascript oder Nicht-Server-Technologien.

Silverlight? MVC mit HTML5? Einfaches MVC? Webformulare mit HTML5? Webformulare planen? 3rd-Party-Kontrollen? (Habe eine Lizenz für Telerik und würde es vorziehen, bei ihnen zu bleiben, es sei denn, es gibt kostenlose / opensource Pakete)

Ich denke, vor einem Jahr wäre Silverlight eine einfache Antwort gewesen, aber jetzt bin ich mir nicht mehr ganz sicher, aufgrund der steigenden Zahl von Android-Geräten, denen die Silverlight-Unterstützung fehlt ... und es scheint, dass Microsoft seinen Fokus verlagert Silverlight zu HTML5

Was bleibt also an Stelle von Silverlight für Business-Apps?

Danke!

    
Igorek 12.09.2011, 04:51
quelle

6 Antworten

3

Wenn Sie planen, iphone / android / non-win zu unterstützen, dann verabschieden Sie sich von silverlight. Wenn Sie die Unterstützung von Smartphones planen, müssen Sie separate Designs für kleine und große Geräte mit großem Formfaktor erstellen. Docking-Schnittstellen sind für kleine Geräte zu überladen.

Technologie? HTML5 wäre nett, aber nur neuere Browser unterstützen es, und selbst dann unterstützen nur Bits & amp; Stücke des Standards.

MVC vs Webformulare? ist nicht wirklich wichtig. beides nur eine Möglichkeit, HTML auszuspucken.

Sie müssen etwas mit Javaskript- oder Nicht-Servertechnologien umgehen. Telerik bietet eine Menge der Komponenten an, die Sie für Webforms erwähnt haben, obwohl sie dazu neigen, sich zu erweitern.

Basierend leicht auf Ihren Anforderungen:

  • Listenansichten: native in webforms / mvc
  • Baumansichten: Telerik oder ein jQuery-Plugin
  • Grids: native HTML-Tabellen funktionieren am besten IMO, oder Sie können eine Datenverbindung in asp.net oder telerik machen
  • Diagramme: kostenloses Plugin, Telerik, Dundas oder etwas wie SSRS, wenn Sie etwas Reporting-Charakter haben
  • docking ui: überdenken Sie Ihre Notwendigkeit dafür. Wenn Sie immer noch interessiert sind asp.net hat Webparts eingebaut oder Sie können ein Paket von jQuery UI erhalten

Insgesamt suchst du vielleicht nach einem "schnellen" Weg, deine App im Web zu aktivieren, aber es sind zwei verschiedene Bestien, die als solche funktionieren. Wenn Sie eine direkte Konvertierung mit jedem verfügbaren Plugin durchführen, werden Sie eine Menge Zeit brauchen, um jede Komponente zu lernen, eine Menge Seitenaufblähung, eine Menge Bugs und es wird sich nie richtig anfühlen. Mein Vorschlag ist es, gleichzeitig zu investieren und zu lernen, wie man eine richtige Website erstellt. kostet auf lange Sicht weniger.

    
Andrew dh 12.09.2011, 05:27
quelle
4

Obwohl ich gerade dabei bin, wo du dich auf der Suche nach UI Nirvana befindest, werde ich mit dem, worüber ich nachdenke, klar kommen.

Ich persönlich denke, dass, wenn Sie bei Microsoft bleiben wollen, aber Ihre App auf Nicht-Windows-Plattformen laufen muss, es nur zwei Spiele in der Stadt gibt. Silverlight und MVC mit einem guten Satz clientseitiger UI-Widgets.

Mein bisheriger Denkprozess kann heruntergebrochen werden auf:

Silverlight ist MVC in puncto Entwicklungsfreundlichkeit (durch echte MVVM / fantastische Datenbindung) und "Reichhaltigkeit" der Benutzeroberfläche mit einem guten Vorsprung überlegen. Aber leider, für Entwickler, spielt es für einen Benutzer keine Rolle, wie einfach es für uns ist.

Der Nachteil von SL, wie von anderen dargelegt, ist, dass es nicht überall läuft, wo man es will. Am spezifischsten ist Android und iOS schwierig (obwohl Sie MonoDroid und Monotouch bewerten sollten).

MVC, von dem ich denke, dass es die beste serverseitige Webapp-Technologie ist, ist SEHR nett, mit zu entwickeln, aber hat einfach nicht die stateful clientseitigen Feinheiten, die SL tut, und Sie müssen sich mit HTML, Javascript und einem zustandslosen Client beschäftigen .

Diese Kommentare zu mildern, ist, dass es ein paar nette Frameworks gibt, die JavaScript fast erträglich machen (ich benutze JQueryUI & amp; wijmo) und eine halb-reiche Client-UI bereitstellen.

Es kommt wirklich darauf an, gegen Reichtum zu reichen. Ich sehe auch, dass MS auf MVC viel Wert legt. Wer weiß, vielleicht werden wir in der Zukunft einige nützliche Tools für die Datenbindung usw. sehen?

    
Joe 12.09.2011 07:22
quelle
1

Ich hatte das ähnliche Projekt und ging für ASP.NET MVC 2 + Teleriks kostenlose MVC-Komponenten , was gut ist Grid / ComboBox Funktionalität.

Ich habe auch jQuery für einige UI-Sachen verwendet. Sie müssen mit Javascript herumspielen, aber Sie tun es mit jQuery, die ich denke, ist die neue Ebene. wie immer IE6 war der Schmerz :)

    
Bek Raupov 12.09.2011 09:10
quelle
1

(Sorry für mein schlechtes Englisch) Ich habe ähnliche Anforderungen wie Sie und entschied mich für Silverlight. Meine Kunden verwenden keine iPads oder Androiden als Arbeitswerkzeug, aber einige Teile meiner App werden von diesen Geräten konsumiert. Für mich wäre es viel mühsamer, alles in html / js zu entwickeln, nur damit die App auf allen Plattformen laufen kann, wenn meine Kunden windows / osx 99% der Zeit benutzen.

Auch Tablets / Smartphones / PCs haben alle unterschiedliche UI-Richtlinien, für mich macht es keinen Sinn diese "html / js überall zu rennen" Sache. Selbst wenn Sie html / js verwenden, müssen Sie eine benutzerdefinierte Benutzeroberfläche auf jeder Plattform erstellen (zumindest für Desktops / Tablets), wenn Sie eine anständige Benutzererfahrung wünschen.

Um die Benutzeroberfläche in Silverlight zu entwerfen ist einfach und mvvm (suchen Sie nach caliburn micro, wenn Sie diese Route gehen) passt gut. Auf dem Server verwende ich die RIA-Services und stelle einen OData-Feed zur Verfügung, damit andere Clients die Daten problemlos konsumieren können.

    
Leo 12.09.2011 19:32
quelle
0

Denken Sie daran, wenn Sie die Silverlight-Route gehen, werden Sie Android, iPhone und Blackberry-Geräte auslassen und nur auf Windows Phones beschränken. Webforms mit MVC ist immer eine gute Option.

Ich bin immer ein großer Befürworter von MVC, wegen der Trennung Ihrer Komponenten und Ansichten und der Abstraktion der Schnittstellen. Webforms sind nett und Sie können AJAX und JQuery verwenden, die damit integriert sind. Die laufen auf den meisten Browsern, AJAX ist eigentlich ziemlich glatt auf Android und iPhone Safari Browsern. Ich habe ASPX-Seiten geschrieben, die den verschiedenen Browsern für verschiedene mobile Geräte entsprechen. Es sind nur einfache Umgebungsvariablen, die Sie angeben können, welcher Browser und welches Mobilgerät gerade geladen wird.

Silverlight- und WAML-Seiten sehen gut aus und sind portabel, aber auf mobilen Geräten ist das nicht überall verfügbar. Es ist jedoch für Desktops auf verschiedenen Plattformen verfügbar.

Plus Telerik Suite kommt mit Silverlight / WPF, Webforms und Winforms und hat jeweils vergleichbare Control für alle drei Formate.

    
ApolloSoftware 12.09.2011 05:04
quelle
0

Eine Sache, die ich in meiner früheren Antwort vergessen habe: Wenn Sie irgendwelche Anforderungen haben, um mit dem Gerät zu interagieren (sei es Windows / Android / iOS / OSX usw.), müssen Sie wirklich eine native Anwendung machen. Es gibt zwar das Versprechen, dass einige der HTML5-Technologien die Möglichkeit haben, so etwas zu tun, aber ich bezweifle es ehrlich - plattformübergreifender nativer Zugriff? und 2) es wird ein langer Weg sein.

Ich habe mich dafür entschieden, die Benutzeroberfläche mehrfach zu schreiben: Einmal in MVC / JQueryUI, was theoretisch "überall" läuft (obwohl dieser überall schnell mit unterschiedlichen Bildschirmgrößen / Formfaktoren abstürzt), und für jede eine native App "interessant" Bereitstellungsszenarien ".

Ich untersuche derzeit Best Practices, um so viel Code wie möglich aus der Praxis herauszuholen. Wenn der Großteil des UI-Codes auf allen Benutzeroberflächen verwendet werden kann, könnte der UI-Teil sehr klein und für ein bestimmtes Gerät optimiert sein. Wenn ich die UI "dumm genug" halten kann, sollte das nicht zu viel von einer Last sein, oder? : -)

    
Joe 13.09.2011 02:07
quelle