C# Server-Client Modeell

[KeepXtreme]

Hi zusammen,

im Moment suche ich eine Möglichkeit, wie ein Client Daten von einem Server bezieht. Ich bin inzwischen über verschiedene Ansätze gestolpert, die mir für meinen Anwendungsfall aber viel zu komplex erschienen.

Prinzipiell soll folgendes geschehen:
Client übermittel (ev.) einen Key und erhält vom Server entweder eine PDF (liegt auf der HDD) oder eine XML (in einem Fall soll ein Druckjob ausgelöst werden)

Die ANsprüche:
*möglichst einfach aufgebaut
*Scalability ist kein Thema, es wird max. 6 Clients geben von denen 5 die meiste Zeit keine Anfragen senden werden
*möglichst einfach zu warten/verwalten weshalb ich daran gedacht hatte, dass in den IIS einzubinden

bisher läuft das ganze mittels PHP auf einem Linux-Server wozu das PDF-Verzeichnis gemountet wurde. Leider verliert der Server immer wieder die Verbindung zum Fileserver obwohl beide VMs auf der gleichen physikalischen Maschine liegen...


Im Moment suche ich Vorschläge, von wo ich überhaupt starte (sprich, welchen Projekttyp in VS ich überhaupt benötige). Ich hab zwar bisher eine (einfache) Webseite in ASP.Net/c# und eine Win8 App programmiert, Serveranwendungen (außer php-Seiten) sind jedoch Neuland für mich...


...und nein, ich bin kein Schüler und ja, das ist ein freiwilliges Projekt und keine bezahlte Arbeit oder Hausaufgabe

 

[inciter]

Also, dass der Web-Server instabil läuft, liegt definitiv nicht an der Tatsache, dass es sich dabei eben um einen Web-Server handelt. Als ich den Beginn deines Posts laß, war "Web-Server" mein erster Gedanke. Exchange-Server werden seit Exchange 2010 ausschließlich über HTTP in Kombination mit IIS angebunden und müssen eine Menge Clients und Kommunikation handeln können. Wenn der Server an sich schon nicht stabil läuft, wird dir jede andere Server-Anwendung auch nichts nützen.

Alternativ zum Web-Server über HTTP könnte ein FTP-Server das auch bieten. Lokal aus dem Netz, reicht die IP als Eintrittskarte, externe Clients müssen sich authentifizieren. Wäre das eine Möglichkeit?

 

[KeepXtreme]

da scheine ich einiges nicht ausreichend klar gestellt haben:

1) Der Webserver selbst ist ein Debian 8.0 mit Apache 2.4 & HHVM und läuft auch stabil. Das einzige was regelmäßig ausfällt ist die Eingebundene Netzwerkfreigabe des Windows-Servers und das ohne aussagekräftige Fehlermeldung (I/O Fehler). Ein Umziehen der Daten ist nicht möglich.
2) Zur Zeit werden die Daten mittels HTTP zu den Clients gesendet, ist also durchaus auch weiterhin eine Option. Ich suche nur nach der "Optimalen" bzw. am besten geeigneten
3) Der Windowsserver verfügt über den IIS z.Z. einzig aufgrund der CA, PHP will ich dort nicht installieren
4) bei einem FTP-Server weiß ich nicht, ob die Windows RT Umgebung noch mitspielt. Netzwerkpfade z.B. sind ohne Filepicker leider nicht möglich...
5) auch der Windowsserver läuft stabil

 

[inciter]

Mit RT könnte es natürlich in vielerlei Hinsicht komplizierter werden. Hier habe ich keine praktische Erfahrung, lediglich grundlegendes theoretisches Hintergrundwissen. Als Stichwort lasse ich hier mal WebDAV fallen. Vielleicht bieten sich hier Möglichkeiten für RT.

Kurzes Brainstorming IIS:
Der IIS bietet ein gutes Aufwand-/Leistungsverhältnis bzgl. Entwicklungsaufwand zum möglichen Funktionsumfang einer Anwendung. Allerdings ist der IIS dabei auch, der mit Abstand, performance-hungrigste Web-Anwendungsserver. Weiterhin bietet der IIS die Möglichkeit für Standard- oder NTLM-Authentifizierung, falls das eine Rolle spielt. In einer Windows-basierten Netzwerkumgebung, gibt es dann auch wenig Kompatibelitätsprobleme und es müssen weniger Kompromisse getroffen werden. Die Skalier- und Erweiterbarkeit sinkt natürlich rapide, wenn darauf keinerlei Rücksicht genommen wird.

Kurzes Brainstorming Apache/nginx (Linux):
Im Vergleich fällt Linux ohne X-Server / Window-Manager lächerlich sparsam und performanter aus, verbraucht weniger Speicher (RAM und DISK) und kann schnell auf eine andere Maschine umgezogen werden. Als Web-Server-Lösung bietet sich eine große Skalierbarkeit, ungeachtet der Clients und dessen Betriebssystemen. LDAP-Anbindungen über die jeweilige Web-Anwendung ist extrem fummelig. Ist LDAP und eine automatische Client-/User-Anmeldung relevant, stellt Linux schon fast ein Ausschlusskriterium dar, allein schon aufgrund der Menge an Anfälligkeiten und Wartungsaufwand. Vielleicht sieht das Mancher anders, aber hier habe ich mir schon oft einen abgebrochen und werde das so schnell auch nicht mehr anpacken.

Oder doch ganz anders?
Vielleicht bieten das, was du suchst, ja auch bereits fertige, selbst gehostete Cloud-Lösungen: OwnCloud oder besser noch SeaFile.

Linux oder doch nicht?
Das Problem mit dem Mounten der SMB-Freigaben wäre natürlich noch zu lösen, sofern du Linux nicht ausschließen möchtest. Hast du dir sowas schon mal angesehen? Andernfalls, könnte man auch an dieser Stelle, über WebDAV, statt SMB nachdenken.

Fazit:
Eine eindeutige Empfehlung kann dir wohl niemand geben, aber ich denke, das ist dir selbst klar. Es gibt immer, teils erhebliche, Cons und Pros - vor Allem, wenn man Linux und Windows nebeneinander stellt. Auch mit vielen Worten, kann ich dir wohl nur Etwas zum Grübeln an den Kopf werfen. Vielleicht hast - oder bekommst - du noch ein paar grundlegende Gedanken, die für dich eine Rolle spielen. Dann denk ich gern nochmal drüber nach.

 

[KeepXtreme]

erstmal danke für deine Anregungen, aber wir reden gerade aneinander vorbei. Weder der Linux-Webserver soll abgeschaltet werden (da laufen ~10 Webseiten, ein MariaDb & HHVM drauf) noch der Windows-Server (DomainController & Fileserver).

was ich suche ist der geschickteste Weg, die Daten von dem Win-Server aus bereitzustellen bzw. im Fall der XML-Daten diese auch zu generieren. Soweit ich dich verstehe würdest du aber eine einfache Webseite schreiben die mir ähnlich zur aktuelleb PHP-Lösung die Daten einfach per HTTP übermittelt?

 

[inciter]

Also, ich glaube nicht, dass wir aneinander vorbei reden. Ich halte nur stark die weitere Nutzung eines Web-Servers vor und differenziere hierbei stark zwischen einer Windows- und Linux-Lösung. Das tue ich nicht zuletzt deshalb, weil du auch RT ins Spiel gebracht hast. Lösungen - auch bereits für andere Zwecke bestehende - generell auszugrenzen, war ebenfalls nicht mein Ziel. Der Fokus lag dabei nur stark auf der von dir gesuchten Lösung, bzw. geplanten Anwendung. Andere Server habe ich in meiner Betrachten erst mal komplett ausgegrenzt.

Und wie gesagt, den geschicktesten Weg wirst du aufgrund der quantitativen Lösungsansätze nicht finden. Wichtig wird am Ende sein, dass es vernünftig und zuverlässig läuft.

Das Ganz als Webseite vorzuhalten, löse am Ende das Problem, Clients flexibel anzubinden - unabhängig von OS oder reduzierten Systemen wie z.B. RT. Und das mit dem geringst möglichen Aufwand. Das war doch dein Ziel, oder?

Genauso, könntest du auch einen eigenen Client entwickeln, der über HTTTP kommuniziert, bzw. Daten/Dateien austauscht. Solange es nur um den Austausch von Dateien geht, käme auch FTP in Frage. FTP-Server sind schlank und können direkt auf dem File-Server laufen, ohne den Performance-Hunger gravierend zu steigern.

Aber in Bezug auf klassischem Windows-Desktop und RT, werden das dann schon zwei Clients, die sich nur eine geringe Code-Basis teilen. Das widerspricht deiner Anforderung nach geringem Aufwand und leichter Wartungsfähigkeit. Kommen vielleicht noch MAC-Clients und Smartphones hinzu, steigt der Aufwand nochmals - gelinde gesagt - enorm.

Vielleicht noch als Idee: Mittels Qt und geringen, leicht erlernbaren C/C++-Kenntnissen, ließe sich mit Hilfe des QWebKit-Moduls, mit wenigen Zeilen ein Anwendungs-Browser, passend zur Anwendung, bauen. Die Anwendung könnte im Wesentlichen aus einem HTML-basierten Datei-Browser plus der von dir gewünschten Funktionen bestehen.

 

[KeepXtreme]

ich habe irgendwie das Gefühl, dass ich dir Informationen vorenthalten habe, die dir bei deiner Einschätzung fehlen, ich versuchs mal zu erklären:

wir haben ein System, dass PDF-Sammlungen (Protokolle) generiert. Dieses System besteht aus 3 Teilen.
a) einer Windows8-App (sideloaded) zur Darstellung & Drucken an unserem Terminal (deshalb die Win-RT Einschränkung). Das Ding hat einen Touchscreen kann jedoch kein Multitouch. Die App zeigt nach Auswahl des Protokolls eine Vorschau an und ermöglicht es den Leuten, einen Druckauftrag an den Server zu senden (das lokale Drucken haben wir abgeschafft, da die Leute nie die Finger von Druckeinstellungen lassen konnten und der Client beim REndern immer ewig gebraucht hat)
b) dem "Merger", der aus den Einzeldateien die Sammlungen generiert und in einem Ordner auf dem Fileserver (Windows) ablegt
c) der Server-Anwendung, die sowohl die XML-Daten über die verfügbaren Protokolle (auch bei Suchanfragen) als auch die PDF-Dateien liefert und die Druckaufträge entgegen nimmt

Mein Ziel ist c), das zur Zeit in PHP geschrieben ist, aus 2 Gründen zu ersetzen:
1) Der Linux-Server verliert regelmäßig die Netzwerkfreigabe obwohl beide VMs auf dem gleichen Host laufen (die Last auf allen Systemen ist ausreichend gering)
2) Der Druck über den Linux-Server klappt nicht zuverlässig (manchmal verweigert die HHVM den execute bis zu einem Neustart ihrer selbst, manchmal rendert GS nicht richtig (schwarze Seiten), manchmal braucht CUPS ewig beim Spoolen (~10min)

Da die Daten auf dem Windows-Server liegen war die Idee, die Server-Anwendung gleich auf diesen mit Umzuziehen. Die Authentifizierung müsste dann halt von Subnetz auf Domain umgestellt werden, aber das ist kein Problem... Was ich suche war eigentlich die einfachste Version (und für Laien verständlichste) um das umzusetzen. Wie gesagt, Scalability ist kein Thema, es greifen max. 5 Clients gleichzeitig auf den Server zu und das ganze wird auch nur im Intranet des Vereins erreichbar sein...

Wiederverwenderbarkeit von Code ist natürlich nett, ist aber bei den Codenmengen von denen wir reden (der Merger z.B. hat nichtmal 500 Zeilen code) nur ein nettes extras. Mit einfach meinte ich eher, dass die Struktur von Laien verstanden werden können sollte...

edit://
die Win-App bezieht die Daten im Moment auch über HTTP: die PDFs mittels BITS, die XAML via HTTPclient

 

[Backslash]

Eine mögliche Lösung wäre weiterhin die Linux-VM zu verwenden und diese holt sich die Daten vom IIS per HTTP. Ich würde eine entsprechende Anwendung in Python schreiben aber PHP tut's auch.
Wirklich schön ist diese Lösung aber nicht.

Wenn alles auf dem Windows Server laufen soll ist mir die Frage noch nicht ganz klar, es scheint als ob do einfach die entsprechenden Informationen über C# nachlesen musst, eine fertige Lösung wird vermutlich keiner bieten können.

 

[KeepXtreme]

da sehe ich den Vorteil nicht von, denn da muss ich den HTTP-Teil eh schreiben. Und dann den Umweg über den Linux-Server zu gehen - naja, ich sehe da keinen Vorteil drin.

Die Frage ist, vereinfacht, was GENAU ich über c# nachlese, sprich, welchen Ansatz ich überhaupt wähle. Da fehlt mir etwas der Überblick, was für (für meine Zwecke sinnvolle) Möglichkeiten es gibt, die Daten zwischen der Win8-App und dem Server auszutauschen... und um das klarzustellen, mir ist bewusst, dass ich das selber schreiben muss - die Frage ist echt nur, nach welchen Konzept)

 

[inciter]

Mir scheint, als verstündest du nicht, bereits gelieferte Informationen zu verwerten. Ich habe mich durchaus bemüht, eine hohe Informationsdichte in meiner Beratung zu bieten. Lösungsansätze zu deinem Problem sind bereits vorhanden. Weiter, deiner Formulierung folgend, entwickelt sich RT als dein Hauptproblem, was in deinem ersten Post eher noch nebensächlich erschien. Es ist vollkommen in Ordnung Hilfe zu suchen, allerdings solltest du auch in der Lage sein, deine Problemstellung sauber zu formulieren und in einen geordneten Kontext zu stellen. Du hast schließlich eine Entwicklung vor dir. Sich hier über die Grundlagen klar zu sein, ist der Anfang deiner Arbeit. Anfang und Ende - oder: "Welches Ergebnis will ich erzielen und welche Grundlage / Grundsituation finde ich vor?" müssen Allem voran klar definiert sein.

RT ist limitiert, soweit sind wir uns einig. Ich habe dir bereits empfohlen, dich einmal mit WebDAV zu beschäftigen. Spräche etwas dagegen, einen Web-Server auf dem File-Server aufzusetzen? Als lightweight Alternative zum IIS könnte man zu Cassini oder Mongoose greifen. Der Austausch von Dateien ließe sich dann bequem über WebDAV realisieren. Einen passenden RT-Client zu entwickeln, sollte dann auch keine große Herausforderung mehr sein. Weitere Funktionen, wie z.B. das Drucken könnten mittels CGI/FastCGI Server-seitig umgesetzt werden. HTTP und WebDAV als Basis bieten dir dann auch die Möglichkeit, die Anwendung bei Bedarf schnell und einfach anzupassen. Und im Notfall kann man auf das WebDAV auch direkt über jeden beliebigen Web-Browser zugreifen.

 

[KeepXtreme]

nochmal danke für deine intensive Beratung. Mein Grund für wenig Informationen war, dass ich niemanden mit der Komplexität des jetztigen Aufbaus erschlagen wollte. Rückwirkend betrachtet war das ein großes Fehler.... sry

gegen einen Webserver auf dem Fileserver spricht nichts bzw. der ist, wie bereits erwähnt, schon vorhanden (IIS für die CA). Aus diesem Grund sollte es der IIS bleiben.

Ich habe mir gerade WebDavr für den IIS angeschaut, scheint wirklich schnell einzurichten/verwendbar zu sein... ich werde mir die Implementierung in WinRT noch anschauen und wenn das sinnvoll einsetzbar ist für, den PDF-Transfer verwenden.
Die eine der beiden XML-Dateien kann ich theoretisch auch per webdav übertragen indem ich sie vorab generiere und auf dem Server ablege...
Für die 2. XML und die Druck-Funktionalität brauche ich jedoch eine Programmlogik und soweit ich WebDav verstehe ich das dafür nicht geeignet/sinnvoll. Sprich, die beiden Funktionen dann direkt über HTTP übertragen?

verstehe ich das dann richtig, das ich in diesem Fall 2 Seiten im ISS einrichten muss, sprich einmal für WebDav und einmal für HTTP da Webdav ja am gleichen Port lauscht? Alternativ WebDav auf HTTPS (wo es ja eh hingehört) und den Rest nur über HTTP (sind keine wichtigen Daten und sie werden auch nur im Intranet übertragen)?

 

[inciter]

Hey, jetzt kommen wir voran. Klar, der IIS läuft schon als CA. Das hatte ich schon wieder ausgeblendet.

Genau! WebDAV als solches ist ja keine Web-Anwendung im eigentlichen Sinne. Es wird einfach nur konfiguriert und fertig. Dann ist es für Clients nutzbar. Für die Bereitstellung erhält WebDAV natürlich eine eigene URL.

Gesonderte Funktionen benötigen dann die eigentliche Anwendung, die auch Server-seitig laufen muss, solange die Clients diese Aufgaben nicht selbst übernehmen sollen. Im IIS würde ich eine Anwendung in C# entwickeln, die ihre Daten über HTTP mittels POST-Formular-Übertragung erhält und daraufhin die entsprechenden Aufgaben ausführt. Das dürfte vom Aufwand auch überschaubar werden.

Auch die zweite XML könntest du per WebDAV übertragen. Der Server könnte das Ablageverzeichnis überwachen und bei einer neuen Übertragung oder dem Überschreiben der alten Daten/Datei entsprechend automatisiert tätig werden. Aber in diesem Fall lassen sich auch noch andere Lösungsansätze finden.

PS: Ich weiß nicht genau, was du mit der "zweiten XML" genau bezwecken möchtest, deshalb setze ich den letzten Absatz nochmal unter Vorbehalt.

 

[KeepXtreme]

das mit der 2. XML wird schwierig (oder mir fehlt noch das wissen bzw. ich weiß nicht, wie du das mit der Überwachung meinst. Ist da POST nicht einfacherer?): Die beiden XML-Dateien stellen im Prinzip meine Verbindung zur SQL-Datenbank da, da WinRT nicht auf Datenbanken zugreifen kann/darf. Die erste liefert dabei immer den kompletten Datensatz und somit könnte die quasi-statisch auf dem Server liegen (der Merger würde die jede Nacht aktualisieren). Mit der 2. ist es schwieriger, da sie für die Suchfunktion der App verwendet wird: Der Client liefert bisher einen Suchstring per POST, der wird escaped und dann eine Suche in der DB durchgeführt. Anschließend werden die Daten als XML wieder an den Client geschickt.

Die Kombination IIS/c# war meine ursprüngliche Idee - allerdings ursprünglich auch zum PDF-Versand (nur 1 Ordner der alle Dateien nach einem festen Namensschema enthält, nur Lesezugriff, keine Benutzerrechte).


IIS:
Bisher liefert die Default-Seite für Port 80 nur ein redirect auf unsere Homepage (die Domäne ist ohne www., die HP allerdings mit) die auf dem Linux-Server läuft.
Wird WebDav an eine bestimmte Seite sprich an eine bestimmte Subdomain gebunden oder läuft das über die DefaultSite und den FQDN?

WebDAv/WinRT:
scheint nicht von Haus aus zu gehen allerdings gibt es wohl eine Bibliothek die das kann...

 

[inciter]

Also, WebDAV in eine RT-Anwendung zu integrieren, sollte möglich ein. Ich kann mir allerdings schon vorstellen, dass .NET das nicht direkt liefert. Vielleicht lässt sich die erwähnte Bibliothek leicht einbinden, dann wäre dieser Teil schon geritzt.

WebDAV erhält einen eigenen Anwendungspool im IIS. Dafür könntest du dann eine neue Website hinzufügen, die unter der URL "deine-domäne.tl/File-System" erreichbar sein könnte, sprich einen eigenen Unterordner / virtuelles Verzeichnis erhält. Hier beginnt dann das Root des WebDAVs. Eine Subdomäne wird nur interessant, wenn du einen separaten externen und eigenständigen Zugang über das Internet anbieten möchtest.

Worüber ich gerade nachdenke... Wenn deine Endanwendung nur als UI/GUI dient, finde ich die Logik bzgl. des Handlings der Datenbanken mit den XML-Dateien/-Daten unnötig kompliziert. RT-Anwendungen unterstützen doch von Haus aus eine gewisse HTML-Konformität, oder täusche ich mich da jetzt? Dann könnte doch die Server-Anwendung die Anfragen direkt von den Clients entgegen nehmen, verarbeiten und das jeweilige Ergebnis direkt an Client zurückgeben. Als Transportweg dient dann eben HTTP, genauso, wie es bei einer Internet-/HTML-Seite auch abläuft: POST/GET.

 

[KeepXtreme]

ok, 1 & 2 sind klar...

Punkt 3 verstehe ich nicht ganz... du wolltest das Ergebnis der Anfrage auf dem Server als HTML-Seite rendern und dann einfach nur noch in der App darstellen? ja, wäre wohl gegangen aber an die Möglichkeit hatte ich beim Schreiben der App gar nicht gedacht. Ursprünglich wollte ich die Daten direkt aus der DB holen bis ich über WinRT und das Nicht-Erlaubtsein gestolpert bin - deshalb die Lösung mit XML.

Ich hab dir Unten mal 2 Screenshots (beim 2.: die schwarze Fläche in der mitte dient normalerweise der PDF-Darstellung) & die XML angehängt, ev. kriegst du dann eine bessere Vorstellung

edit:// in der App benutze ich z.Z. Backgroundtransfer um die PDF runter zu laden und der scheint webdav zu unterstützen. Macht da Webdav überhaupt sinn oder reicht es, die Dateien direkt per HTTP anzubieten/verfügbar zu machen (also ähnlich wie das der Apache macht, wenn man eine Datei anfragt, die er nicht interpretiert. sprich, reicht nicht static Content völlig für meine Zwecke)?

 

[inciter]

Naja, wie ich zuvor schon mal sagte, am Ende zählt nur das Ergebnis. Wichtig ist, deine Dateien in die App zu bekommen. Gleiches gilt für alle andere Daten. WebDAV ist ja nichts anderes als eine einfache Web-Anwendung, die dir Inhalte von Verzeichnissen / Ordnern anzeigt / auflistet und diese automatisch zum Download verlinkt. Natürlich kannst du deine App auch anweisen sich wie ein Browser zu verhalten und die Dateien direkt runterzuladen. WebDAV erleichtert dir ja hauptsächlich die Arbeit, Dateien zu veröffentlichen, bzw. den Clients bekannt zu machen.

Zur Frage... ich wollte dir nicht empfehlen HTML vor zu rendern, sondern lediglich HTTP als Transport zu nutzen. Hier ist mir aber noch eine andere, nahe liegende Lösung in den Sinn gekommen: JSON. Für C# gibt es hier eine Projekte zum Seriallisieren von JSON-Objekten / -Daten. Viele andere Web-Projekte verwenden bereits JSON-APIs zum Datenaustausch zwischen Server und Clients - z.B. TheMovieDB, TheTVDB oder ein installiertes Kodi Media Center (ehem. XBMC).

JSON kann server-/cient-seitig sowohl für Requests, als auch für Responses verwendet werden und du hast keinen HTML-Code, oder HTML-Dateien, da die Anwendung ausschließlich mittels JSON kommuniziert.

Bei deiner Frage [...] "die Dateien direkt per HTTP anzubieten/verfügbar zu machen (also ähnlich wie das der Apache macht, wenn man eine Datei anfragt, die er nicht interpretiert. sprich, reicht nicht static Content völlig für meine Zwecke)?" ...tue ich mich gerade inhaltlich etwas schwer. Besonders [...] "die er nicht interpretiert" [...] kann ich nicht interpretieren und was du insbesondere mit "static Content" meinst, bzw. welche vom Server angebotenen Daten "static" sein sollen.

 

[KeepXtreme]

mit dem static content meine ich alle Dateien, die nicht zuerst von einem Interpreter ausgeführt werden (z.B. aspx, php, ...) sondern die direkt an den Client (Browser) geschickt werden (html, css, images, pdf,...). Also genau das, das direkte Runterladen durch die App.

Da ich:
a) den Dateinamen &Pfad kenne, da sich der Name stehts aus dem Key.pdf zusammensetzt und ich
b) nur lesenden Zugriff brauche
sehe ich nicht so ganz was der Vorteil durch die Verwendung von webdav in diesem Fall sein soll. Vor allem, da der download sowohl als backgroundtransfer als auch mit httpclient ein Ding weniger Zeilen ist. (wobei mir der Vorteil durchaus einleuchtet, wenn ich NICHT weiß, was an Dateien vorhanden ist)

gut, JSON wäre ein Möglichkeit gewesen an die ich schlicht und ergreifend nicht gedacht habe (auch mangels meiner Erfahrung in dem Bereich).


meine ursprüngliche Frage hast du weitgehend beantwortet: ich wollte wissen wie ich die Daten am besten vom Server zum Client kriege und die Antwort ist IIS (und nicht z.B. ein eigener Windows-Dienst oder WCF.
Soweit ich das jetzt verstanden habe, muss ich einen Webdienst in C# schreiben. Reicht mir da eine Datei? So nach dem Motto getAll(), doSearch(), print() - also als Methoden in einer asmx. Oder besser auf verschiedene Dateien aufteilen? Oder bin ich gerade völlig auf dem Holzweg?

 

[inciter]

Also natürlich kannst du alle Daten bereits als HTML anbieten, wobei ich mich dann frage, ob die Nutzung eines Browsers am Client dann nicht von vornherein die bessere Option wäre. Zumal man ja auch einen Kiosk einrichten kann, falls das dein Wunsch sein sollte.

Wenn sich sowieso ein IIS anbietet, da dieser bereits auf dem File-Server läuft, ist das wohl die beste Option. Ihn nicht zu nutzen wäre Quatsch.

Wie komplex du deine Web-Anwendung gestaltest, liegt natürlich bei dir. Aber sicherlich kannst du alle Funktionen auch in einer einzigen Klasse definieren. Was letztendlich an den Client zurück geliefert wird, entscheidet dieser durch seine Anfrage. Prinzipiell würde ich bei deinem Projekt trennen zwischen Präsentation und einfachen Funktionen, wie dem Drucken: eine Seite für die PDFs (Übersicht und Anzeige) und eine Klasse für die Features (z.B. Drucken).

 

[KeepXtreme]

wir hatten früher eine WEbseite am Kiosk mit Links zu den PDF. Hat nur äußerst bescheiden funktioniert, was an der schlecht gestalten HP, dem fehlenden Multitouch und der Notwendigkeit 2 Apps parallel (IE & PDF Reader) zu verwenden lag. Ich wollte mit dem statischen Content eigentlich nur sagen, dass ich den Download der PDF direkt über HTTP realisieren wollte/will und das die zusätzlichen Features mir in meinem Fall nichts bringen. HTML selbst hatte ich nicht vor.

die "Präsentation" der PDF-Dateien benötigt ja keinen eigenen Code. Die beiden XML-Dateien sollten eh in eine Datei, da sie sich einiges an Code Teilen. Die Frage ob die Druckfunktion in einer eigenen Datei liegt ist demnach aber geschmackssache..?