nicht angemeldet
Der Martin
Der Martin
Der Martin
Der Martin
Der Martin
at
Hallo zusammen!
Ich beschäftige mich derzeit mit HTML, Webseiten, so bisschen Programmiersprachen..... Im Zuge meiner Recherchen bin ich auf die Begriffe "Webanwendungen" und "Softwareanwendungen" gestoßen. Den Unterschied zwischen den beiden Programmen kenne ich inzwischen so ungefähr.
Dabei stellt sich mir nun die Frage:
Worin bestehen die jeweiligen Vor- und Nachteile von Webanwendungen und Softwareanwendungen? Wann empfiehlt sich die Erschaffung des einen und wann des anderen?
Wäre toll, wenn ihr mir bei der Lösung dieser Frage behilflich sein könntet. :)
Viele Grüße,
bea
Abend,
einen habe ich noch!
Worin bestehen die jeweiligen Vor- und Nachteile von Webanwendungen und Softwareanwendungen? Wann empfiehlt sich die Erschaffung des einen und wann des anderen?
"Webanwendungen" sind HTML/XML und HTTP(S) und so weiter basiert. Das ist cool, denn diese laufen so zu sagen plattformunabhaengig mit Hilfe des jeweils vorhandenen Browsers. Und man kann so schoen mit den einzelnen Schichten (Datenschicht/HTML+CSS-Praesentationsschicht/JavaScript, damit bspw. nur clientseitig was laueft) arbeiten, das finden Entwickler meist ganz toll.
"Fette SW" empfiehlt sich, wenn man etwas entwickeln moechte, das rein clientseitig laueft bzw. SpezialSW (grafiklastige SW oder andere CPUZeit-Fresser z.B.) darstellt.
Bockie
Hallo,
"Fette SW" empfiehlt sich, wenn man etwas entwickeln moechte, das rein clientseitig laueft bzw. SpezialSW (grafiklastige SW oder andere CPUZeit-Fresser z.B.) darstellt.
ja, nur dass das, was du hier mit "Fette SW" bezeichnest, die beste Chance hat, in Wirklichkeit "schlanke SW" zu werden - jedenfalls, wenn der Programmierer was auf dem Kasten hat. Denn wenn man die reine Anwendung programmiert, erhält man in der Regel einen wesentlich kompakteren und damit auch oft schnelleren und weniger ressourcenhungrigen Code, weil eben alles wegfällt, was für die jeweilige Applikation nicht gebraucht wird.
Ciao,
Martin
Abend,
"Fette SW" empfiehlt sich, wenn man etwas entwickeln moechte, das rein clientseitig laueft bzw. SpezialSW (grafiklastige SW oder andere CPUZeit-Fresser z.B.) darstellt.
ja, nur dass das, was du hier mit "Fette SW" bezeichnest, die beste Chance hat, in Wirklichkeit "schlanke SW" zu werden - jedenfalls, wenn der Programmierer was auf dem Kasten hat. Denn wenn man die reine Anwendung programmiert, erhält man in der Regel einen wesentlich kompakteren und damit auch oft schnelleren und weniger ressourcenhungrigen Code, weil eben alles wegfällt, was für die jeweilige Applikation nicht gebraucht wird.
vermutlich sind die Adjektive 'fett' und 'schlank' fuer den Vergleich von so genannten Webanwendungen und lokal auf einem Rechner laufender Software nur begrenzt geeignet.
Allerdings scheint mir bspw. Windows-SW keinesfalls "schlank", selbst wenn der Code auf unzaehlige nachladbare Bibliotheken verteilt ist.
Die Kernfrage scheint mir zu sein:
Ist die Windows-API (oder eine andere OS-API) bzw. die darauf liegenden Schichten einfach und effizient zu nutzen?
Falls nein, so darf das Adjektiv "fett" (ganz vorsichtig ;) verwendet werden.
Bockie
Hallo,
vermutlich sind die Adjektive 'fett' und 'schlank' fuer den Vergleich von so genannten Webanwendungen und lokal auf einem Rechner laufender Software nur begrenzt geeignet.
ja, es wäre ungerecht, diese grundverschiedenen Programmieransätze so zu vergleichen.
Allerdings scheint mir bspw. Windows-SW keinesfalls "schlank", selbst wenn der Code auf unzaehlige nachladbare Bibliotheken verteilt ist.
Das liegt aber daran, dass diese Anwendungen meist auf Standardbibliotheken (z.B. MFC, VB-Runtime o.ä.) aufbauen, die selbst schon überfettet sind.
Die Kernfrage scheint mir zu sein:
Ist die Windows-API (oder eine andere OS-API) [bzw. die darauf liegenden Schichten] einfach und effizient zu nutzen?
Definitiv: Ja. Ich habe kein Problem, Windows-Applikationen ausschließlich unter Verwendung der Windows-API (also ohne zusätzliche Bibliotheken) zu programmieren, die bei vergleichbarem Funktionsumfang nur einen Bruchteil des Ressourcenbedarfs anderer, teils kommerzieller Lösungen haben. Sowohl im Hinblick auf den Bedarf an Arbeitsspeicher, als auch die Größe der Executables, als auch den Bedarf an CPU-Power.
Das ist auch kein Wunder, denn die typischen Bibliotheken sind als eierlegende Wollmilchsäue angelegt und bringen Hunderte von Funktionen und Möglichkeiten mit (von denen viele sogar per Default aktiv sind), die in der konkreten Applikation gar nicht genutzt werden.
Falls nein, so darf das Adjektiv "fett" (ganz vorsichtig ;) verwendet werden.
Lieber nicht - oder nur dann, wenn
a) Web-Anwendungen
b) auf Fremdbibliotheken basierende Softwareanwendungen und
c) rein API-basierende Anwendungen
alle in einer eigenen Liga spielen und nur mit ihresgleichen gemessen werden.
Schönen Abend noch,
Martin
Hi,
[...] Ich habe kein Problem, Windows-Applikationen ausschließlich unter Verwendung der Windows-API (also ohne zusätzliche Bibliotheken) zu programmieren,
wow!
die bei vergleichbarem Funktionsumfang nur einen Bruchteil des Ressourcenbedarfs anderer, teils kommerzieller Lösungen haben.
Ach, eine Einschraenkung. Dann kann ich das aber auch! (Vorausgesetzt etliche Manntage duerfen geblockt werden.)
Falls nein, so darf das Adjektiv "fett" (ganz vorsichtig ;) verwendet werden.
Lieber nicht - oder nur dann, wenn
a) Web-Anwendungen
b) auf Fremdbibliotheken basierende Softwareanwendungen und
c) rein API-basierende Anwendungen
alle in einer eigenen Liga spielen und nur mit ihresgleichen gemessen werden.
OK, ich werde Windows-SW nicht mehr als "fett" bezeichnen, auch und gerade nicht mehr im uebertragenden Sinne.
So, ich muss jetzt aber wirklich Bunni machen...
Schoenen Abend noch!
Bockie
n'Abend,
[...] Ich habe kein Problem, Windows-Applikationen ausschließlich unter Verwendung der Windows-API (also ohne zusätzliche Bibliotheken) zu programmieren,
wow!
naja, wieso "wow"? So isses am einfachsten ...
die bei vergleichbarem Funktionsumfang nur einen Bruchteil des Ressourcenbedarfs anderer, teils kommerzieller Lösungen haben.
Ach, eine Einschraenkung.
Was für eine Einschränkung? Ich hab keine gesehen.
Nee, aber mal ehrlich: Das Windows-API kenne ich relativ gut, damit komme ich klar, zumal es recht gut dokumentiert ist. Ergo komme ich damit deutlich schneller zum Ziel, als wenn ich etablierte Standardbibliotheken wie MFC, OCF und wie sie alle heißen, verwenden sollte. Denn auch wenn sie einzelne Aufgabenstellungen erleichtern, so werfen sie einem doch an viel mehr Stellen Knüppel zwischen die Beine. Deswegen ist meine Devise, wann immer ich das selbst entscheiden kann: Pure API programming.
OK, ich werde Windows-SW nicht mehr als "fett" bezeichnen, auch und gerade nicht mehr im uebertragenden Sinne.
Schön - auch wenn das auf viele Windows-Anwendungen leider dennoch zutrifft. ;-)
So, ich muss jetzt aber wirklich Bunni machen...
Äh, was bitte?
Ciao,
Martin
Hallo dem Martin,
[...] Ich habe kein Problem, Windows-Applikationen ausschließlich unter Verwendung der Windows-API (also ohne zusätzliche Bibliotheken) zu programmieren,
wow!naja, wieso "wow"? So isses am einfachsten ...
hoehoe, irgendwie hast Du da natuerlich recht.
Nee, aber mal ehrlich: Das Windows-API kenne ich relativ gut, damit komme ich klar, zumal es recht gut dokumentiert ist. Ergo komme ich damit deutlich schneller zum Ziel, als wenn ich etablierte Standardbibliotheken wie MFC, OCF und wie sie alle heißen, verwenden sollte. Denn auch wenn sie einzelne Aufgabenstellungen erleichtern, so werfen sie einem doch an viel mehr Stellen Knüppel zwischen die Beine. Deswegen ist meine Devise, wann immer ich das selbst entscheiden kann: Pure API programming.
Ich bin ganz ernsthaft sehr beeindruckt. Noch nie habe ich jemanden getroffen, der eine direkte Nutzung der Windows-API propagiert.
Cool. Was entwickelst Du denn so? Auch groessere Sachen?
So, ich muss jetzt aber wirklich Bunni machen...
Äh, was bitte?
Slangausdruck.
Bockie
Yo Mahlzeit,
naja, wieso "wow"? So isses am einfachsten ...
hoehoe, irgendwie hast Du da natuerlich recht.
:-)
[...] Pure API programming.
Ich bin ganz ernsthaft sehr beeindruckt. Noch nie habe ich jemanden getroffen, der eine direkte Nutzung der Windows-API propagiert.
Das hat historische Gründe. Ich bin als Teenager in den 80er Jahren mit dem C64, den damals "jeder" hatte, in die Computerwelt reingestolpert. Ich war noch nie der klassische Spiele-Typ, ich fand es eher spannend, selbst was auf die Beine zu stellen, sei es Software oder auch Hardware. Ziemlich schnell habe ich am legendären "Brotkasten-Computer" gemerkt, dass mit dem integrierten BASIC kein Blumentopf zu gewinnen war, hab mich also in die Assembler-Programmierung gestürzt. Das hat mich fasziniert: Man konnte plötzlich jedes Fitzelchen am Verhalten eines Programms selbst beeinflussen und Funktionen realisieren, die man selbst nie für möglich gehalten hätte (und die Kameraden oft auch nicht). Und diese Art der Programmierung war natürlich bei der Kiste ideal, da man so Speicher und Rechenleistung bestmöglich ausnutzen konnte.
Die Grundeinstellung hat sich bei mir bis heute erhalten: Programmiere so systemnah und so effizient wie möglich, versuche schon beim Compilieren, alles wegzulassen, was für das aktuelle Projekt nicht nötig ist, optimiere den Code selbst und verlass dich nicht darauf, dass der Compiler das macht (meistens tut er das nämlich nicht so gut).
Die Verwendung von herkömmlichen Bibliotheken widerspricht dieser Einstellung natürlich komplett. Diese Libraries bringen oft tonnenweise Code mit, der in der konkreten Applikation nicht gebraucht wird, aber für das Funktionieren der Gesamtbibliothek oft mit initialisiert und benutzt werden muss. Ergo bin ich auch bei der Windows-Programmierung wieder auf die niedrigste Abstraktionsstufe gekommen, die mit vertretbarem Aufwand handhabbar ist: Programmierung in C (ungern C++), teils mit Assembler gemischt, auf API-Ebene.
Cool. Was entwickelst Du denn so? Auch groessere Sachen?
Kommt drauf an, was du unter "größer" verstehst. ;-)
Ein Konkurrenzprodukt zu Office war's noch nicht gerade, aber doch ein paar ganz nette Projekte. Vor langer Zeit eine einfache Planetarium-Simulation, dann mal eine Auswerte- und Anzeigesoftware für ein Funkuhr-Empfängermodul; das größte Projekt bisher war wohl eine Mess- und Regelanwendung (mit Messwerterfassung, Protokollierung, Plausibilitätsbewertung, Darstellung als Tabellen oder Graphen, Reaktion auf bestimmte Triggerbedingungen etc.), die wir seit Jahren im Labor benutzen.
Bunni machen...
Äh, was bitte?
Slangausdruck.
Hm, okay. Jetzt weiß ich so viel wie vorher.
Schönes Wochenende,
Martin
Hi,
[...] Das hat mich fasziniert: Man konnte plötzlich jedes Fitzelchen am Verhalten eines Programms selbst beeinflussen und Funktionen realisieren, die man selbst nie für möglich gehalten hätte (und die Kameraden oft auch nicht). [...]
brrrr...
Ich erklaere hiermit, dass ich nie SW schreiben moechte wegen Fitzelchen und so.
Aber beim MS SQL Server mache ichs eigentlich auch so (da lohnt es sich fuer mich). Ich lasse diesen ADO/DAO/ActiveXWuerg (nach "einigen" schlechten Erfahrungen) aussen vor und "exekutiere" T-SQL (SPs).
Cool. Was entwickelst Du denn so? Auch groessere Sachen?
Kommt drauf an, was du unter "größer" verstehst. ;-)
Ein Konkurrenzprodukt zu Office war's noch nicht gerade, aber doch ein paar ganz nette Projekte. Vor langer Zeit eine einfache Planetarium-Simulation, dann mal eine Auswerte- und Anzeigesoftware für ein Funkuhr-Empfängermodul; das größte Projekt bisher war wohl eine Mess- und Regelanwendung (mit Messwerterfassung, Protokollierung, Plausibilitätsbewertung, Darstellung als Tabellen oder Graphen, Reaktion auf bestimmte Triggerbedingungen etc.), die wir seit Jahren im Labor benutzen.
Fuer die FinanzdienstleistungsSW, an der ich meist herumdoktore, brauche ich die WindowsAPI also nicht.
Kannst Du mir vielleicht noch einen Lesetipp geben, also wo ich nachlesen kann wie ich das Programmgeruest (Datenzugriff auf RDBMS, GUI ("MDI-Project" ;) und Navigation) hinkriege [b]und[/b] welches Spezialwissen um MS Windows ich benoetige um mal was rein Windows-API basiertes zu machen? Um den initialen Lern- und Entwicklungsaufwand abschaetzen zu koennen.
Bockie
Hallihallo,
Aber beim MS SQL Server mache ichs eigentlich auch so (da lohnt es sich fuer mich). Ich lasse diesen ADO/DAO/ActiveXWuerg (nach "einigen" schlechten Erfahrungen) aussen vor und "exekutiere" T-SQL (SPs).
davon hab ich jetzt zwar kaum ein Wort verstanden, weil dieses Datenbank-Gelump für mich wieder eine Ansammlung böhmischer Dörfer ist - und ich verspüre auch nicht die geringste Lust, mich da einzuarbeiten. Vielleicht auch deshalb, weil ich noch nie einen Anwendungsfall hatte, wo ich sowas sinnvoll hätte einsetzen können?
Fuer die FinanzdienstleistungsSW, an der ich meist herumdoktore, brauche ich die WindowsAPI also nicht.
Vermutlich nicht, "brauchen" ist sowieso der falsche Ausdruck. _Wie_ man an eine Programmier-Aufgabe herangeht, ist zum großen Teil Geschmackssache, man könnte auch sagen, eine Glaubensfrage. Der eine schwört auf Delphi, ein anderer auf Wuschel-Basic, und wieder andere wollen nur Plain C. Manche, so wie ich zum Beispiel, sogar am liebsten mit dem alten, aber bewährten Borland-Compiler (Borland C 5.01), weil mir die MSVC-Umgebung viel zu riesig und aufgebläht ist, und weil mir die Microsoft-IDE zu viel in meinem Quellcode rumfummelt und ungefragt geheimnisvolle includes oder Definitionen reinschreibt.
Kannst Du mir vielleicht noch einen Lesetipp geben, also wo ich nachlesen kann wie ich das Programmgeruest (Datenzugriff auf RDBMS, GUI ("MDI-Project" ;) und Navigation) hinkriege [b]und[/b] welches Spezialwissen um MS Windows ich benoetige um mal was rein Windows-API basiertes zu machen?
Hmm, gute Frage. Bei mir hat sich dieses Wissen über Jahre angesammelt, es ist unglaublich schwer, jemandem jetzt einen Tipp zu geben, wie er, sagen wir mal, in wenigen Stunden einen Einblick bekommen kann. Das Grundkonzept kann man aber, wenn man etwas Programmiererfahrung hat, recht schnell verstehen.
Wenn du weiter ins Detail gehen möchtest, frag mal Google nach "Windows API programming", und schau dir ein paar der zahlreichen Fundstellen an (da ist allerdings viel Ramsch dabei). Und wenn du dann sicher bist, dass du für diesen Schritt eventuell bereit bist, Geld auszugeben, dann kann ich als Standardliteratur "den Petzold" empfehlen. Der Schinken ist nicht ganz billig, aber die Ausgabe lohnt sich.
Schönes Wochenende noch,
Martin
Hi,
Aber beim MS SQL Server mache ichs eigentlich auch so (da lohnt es sich fuer mich). Ich lasse diesen ADO/DAO/ActiveXWuerg (nach "einigen" schlechten Erfahrungen) aussen vor und "exekutiere" T-SQL (SPs).
davon hab ich jetzt zwar kaum ein Wort verstanden, weil dieses Datenbank-Gelump für mich wieder eine Ansammlung böhmischer Dörfer ist - und ich verspüre auch nicht die geringste Lust, mich da einzuarbeiten.
da gehts darum den Programmierer MS-süchtig zu machen. Die offizielle Sprachregelung ist natürlich eine andere: Es wird behauptet, dass das Einziehen spezieller Schichten zwischen RDBMS und Anwendung (bspw. die spezielle Datenschicht MS ADO ("active data objects" - würg!)) für den Entwickler die Vorteile a) Unabhängigkeit vom RDBMS (man hängt einfach ein anderes RDBMS an und "ADO macht das schon", "funzt" aber leider "net") und b) vereinfachter Datenzugriff mit sich bringen.
Vielleicht auch deshalb, weil ich noch nie einen Anwendungsfall hatte, wo ich sowas sinnvoll hätte einsetzen können?
Den sehe ich auch nicht. Viele Kollegen sind auf diese Datenschichten sehr schlecht zu sprechen, u.a. weil sie dazu verfuehren katastrophal schlechten Datenzugriffscode zu schreiben (um präziser zu sein, der Code sieht oberflächlich betrachtet oft ganz brauchbar aus, aber die MS-Datenzugriffsschicht generiert sehr ineffizienten SQL-Traffic).
[...] Manche, so wie ich zum Beispiel, sogar am liebsten mit dem alten, aber bewährten Borland-Compiler (Borland C 5.01), [...] Das Grundkonzept kann man aber, wenn man etwas Programmiererfahrung hat, recht schnell verstehen. [...] Google nach "Windows API programming", [...] den Petzold .
Danke! Das letztgenannte Buch hatte ich vor Jahren mal in der Hand. Schon damals drohten 5k Funktionen und Spezialkenntnisse um das Betriebssystem MS Windows. (Damals gabs sogar noch zwei davon. ;)
Ähh, ich weiss nicht, habe irgendwie den Verdacht, dass sich diese Lerninvestition für mich nicht rechnet. Schade eigentlich. Und wenn ich an das dann pflichtige Abo der API-Funktionen Updates denke. ;)
Letzte Frage noch: Wo tauscht Du Dich aus mit Deinen "Hardcore-Kollegen"?
Viele Grüße!
Säbelzahnigelchen
Hallo,
davon hab ich jetzt zwar kaum ein Wort verstanden, weil dieses Datenbank-Gelump für mich wieder eine Ansammlung böhmischer Dörfer ist - und ich verspüre auch nicht die geringste Lust, mich da einzuarbeiten.
da gehts darum den Programmierer MS-süchtig zu machen. [...]
nein, wenn ich sagte "kein Wort verstanden" und "keine Lust mich einzuarbeiten", dann meinte ich den Themenkomplex Datenbanken insgesamt. Dafür hatte ich bisher noch keinen Bedarf, und meine Begeisterung ist ungefähr so groß wie für Blasmusikkonzerte: Ich mach einen großen Bogen drum.
den Petzold.
Danke! Das letztgenannte Buch hatte ich vor Jahren mal in der Hand. Schon damals drohten 5k Funktionen und Spezialkenntnisse um das Betriebssystem MS Windows. (Damals gabs sogar noch zwei davon. ;)
Wieso "drohten"? Du meinst "lockten"? ;-)
Und zwei wovon? Zwei Bände des Buchs? Oder zwei Windowse?
Ähh, ich weiss nicht, habe irgendwie den Verdacht, dass sich diese Lerninvestition für mich nicht rechnet. Schade eigentlich. Und wenn ich an das dann pflichtige Abo der API-Funktionen Updates denke. ;)
Was für'n Abo? Was für Updates? Wenn das Windows-API Zuwachs bekommt (neue Windows-Komponenten oder Versionen), dann lädt man sich die aktuelle Fassung des Platform SDK herunter - oder wenigstens die spannenden Teile davon. Wenn's geht, noch ein paar Anwendungsbeispiele im Quellcode.
Letzte Frage noch: Wo tauscht Du Dich aus mit Deinen "Hardcore-Kollegen"?
Tja, das ist so'n Problem. Welche "Hardcore-Kollegen"? Diese Sorte ist sehr selten, und ich fühle mich da immer als Einzelkämpfer. Wenn ich nicht mehr weiter weiß, ist es oft schwer, jemanden zu finden, der's weiß. Stunden- oder tagelange Webrecherchen sind die Folge, das Mitlesen oder Fragen in diversen Newsgroups und/oder Fachforen.
Schönes Wochenende noch,
Martin
Säbelzahnigelchen
nett ... gefällt mir!
Hallo.
Das hat historische Gründe. Ich bin als Teenager in den 80er Jahren mit dem C64, den damals "jeder" hatte, in die Computerwelt reingestolpert.
Und Asterix stand dabei auf der Datasette.
MfG, at
Hallo Forum,
[...] Ich habe kein Problem, Windows-Applikationen ausschließlich unter Verwendung der Windows-API (also ohne zusätzliche Bibliotheken) zu programmieren,
wow!naja, wieso "wow"? So isses am einfachsten ...
Was für Software programmierst du denn so?
Ich habe selbst gerade angefangen, Desktop-Anwendungen zu schreiben,
ich verwende dabei PHP 5.1, PHP-GTK 2.0.0 Alpha und SQLite 3 über PDO,
wobei mich die Stabilität von GTK und der Geschwindigkeitsunterschied
zwischen Prepared Statements und normalen schwer beeindruckt hat (erstere sind doppelt so schnell).
Gegenüber der Windows-API habe ich den Vorteil, dass das ganze plattformunabhängig ist, wenn man darauf achtet, Verzeichnisse durch / zu trennen, was unter Windows auch funktioniert.
Vielleicht ist das dann hundertmal langsamer als die WinAPI, aber ich schreibe auch keine Anwendungen zur Video-Bearbeitung :-)
Gruß
Alexander Brock
Hallo,
[...] ausschließlich unter Verwendung der Windows-API zu programmieren,
wow!
naja, wieso "wow"? So isses am einfachsten ...
Was für Software programmierst du denn so?
ganz unterschiedlich, überwiegend kleine Utilities zum eigenen Gebrauch.
Für die Firma sind es dann aber ab und zu auch Sachen im Bereich "Messen Steuern Regeln", teilweise Datenerfassung und -darstellung in nahezu Echtzeit. Also Sachen, wo's durchaus nützlich ist, wenn die Software möglichst flott läuft, zumal für den Laborbetrieb meistens nur die alten Rechner zur Verfügung stehen. Ein 500er P3 ist momentan das Edelgeschoss.
Gegenüber der Windows-API habe ich den Vorteil, dass das ganze plattformunabhängig ist, ...
Ja, wenn das von vornherein ein Ziel ist, sieht's anders aus. In der Regel ist es bei mir aber eher so, dass eine Applikation speziell für eine gegebene Plattform (meistens eben Win32 auf x86) vorgesehen ist.
wenn man darauf achtet, Verzeichnisse durch / zu trennen, was unter Windows auch funktioniert.
Stimmt - aber nicht in allen Fällen. Ich meine, ich hätte vor kurzem mal eine Situation gefunden, wo der '/' als Verzeichnistrenner nicht akzeptiert wird. Abgesehen davon, dass unter DOS/Windows der Slash '/' typischerweise benutzt wird, um Kommandozeilenschalter anzugeben.
Vielleicht ist das dann hundertmal langsamer als die WinAPI, aber ich schreibe auch keine Anwendungen zur Video-Bearbeitung :-)
Ich auch nicht - aber oft ist es aben doch entscheidend, dass z.B. eine FFT von einem Messzyklus fertig ist.
Schönes Wochenende,
Martin
Moin bea!
Webanwendungen bestehen IHMO aus Serverseitigen Sprachen (PHP/Perl etc.) für den Programmablauf, und aus HTML/CSS als Ausgabeform. Diese sind, sehr Plattformunabhängig, da sie auf quasi jedem Server laufen auf dem die entsprechende Serverseitige Sprache installiert ist, was häufig Standard ist. Webanwendungen sind dann nützlich wenn du Programmabläufe beispielsweise auf einer website benötigst, zB Foren, CMS, oder auch ein normales Gästebuch oder bei Interaktionen mit Datenbanken.
Softwareanwendungen sind Programme die auf Deinem eigenen PC laufen. Sie sind dann brauchbar, wenn du etwas programmieren möchtest was bei vielen Leuten läuft, und mit dem Anwender PC arbeitet (Dateifunktionen, Grafik etc.).
tschüssi
ichen
In den bisherigen Beiträgen wurde eines übersehen!
Softwareanwendungen sind umfassender.
So gibt es noch immer die Software auf den Großrechnern.
Hallo bea,
Was Webanwendungen sind, wird ja aus dem Begriff eigentlich schon klar: Anwendungen, die per Web zugreifbar sind, deren Oberfläche also idr mit HTML und vielleicht noch mit Flash, Appletts o.ä. realisiert ist.
Softwareanwendung ist irgendwie ein unsinniger Begriff, alle Anwendungen sind nunmal Software. Ok, man könnte vielleicht über mechanische Umsetzungen nachdenken ;-)
Zwei gängige Begriffe, die Du meinen könntest, fallen mir da ein:
Desktopanwendung: Das ist eben eine Anwendung die auf einem Desktop läuft (im Gegensatz zu einer Webanwendung, die (zum größten Teil) auf einem Server ausgeführt wird).
Anwendungssoftware/-programm: Software, mit der direkt ein Anwender interagiert.
Der Vorteile von Webanwendung sind im Wesentlichen:
Die Nachteile:
Allgemein kann man wohl sagen: Jede Webanwendung kann man auch als Client in Form einer Desktopanwendung realisieren. Die Realisierung ist dann einfacher und das Ergebniss wahrscheinlich benutzerfreundlicher, das Deployment (und evtl. die Plattformunabhängigkeit) machen dann aber mehr Probleme. Wenn der Anwender überhaupt nicht bereit ist, sich etwas zu installieren (und das dürfte bei vielen Webanwendungen der Fall sein), hat man schon keine Wahl mehr.
Desktopanwendungen kann man, wenn sie eher einfach sind, als Webanwendungen realisieren. Google macht ja sowas. Für typische Desktopanwendung (Grafikprogramm, Textverarbeitung, ...) ist das aber entweder nicht machbar oder extrem aufwendig.
Grüße
Daniel
Hi,
- Realisierung von GUI ist schwierig. HTML, JS und CSS eignen sich schlicht nicht für GUIs und zusätzlich muss man mit der eigentlichen Anwendung auch noch mit HTTP kommunizieren. Das bringt also nicht tolle Schichten, wie Bockie sagt, sondern ist erstmal Gift für eine brauchbare Architektur. Es gibt natürlich unzählige Technologien, um das Problem einigermaßen Herr zu werden.
ich lese da irgendwie heraus, dass
Und was ist für Dich ein GUI, hmmm...
BTW - hast Du schon mal - bspw. mit MSVS - eine Windows Applikation entwickelt? Da wirst Du doch zum Vermischen aller Schichten so zu sagen höchstpersönlich eingeladen.
Säbelzahnigelchen
Hallo Säbelzahnigelchen,
- "Webanwendungen" nicht ganz vollwertig sind
Nun, man hat deutlich weniger Möglichkeiten die GUI zu gestalten als bei Desktoabwendungen. Ich denke, das ist offensichtlich.
- Bockie unrecht hat, wenn er behauptet, dass "Webanwendungen" die Trennung zwischen den Schichten (Datenschicht, "Programmverwaltungsschicht" und Präsentationsschicht) unterstützt
Ja, insbesondere mit der aussage, dass JS, HTML und CSS dies tun würden. Üblicherweise realisiert ein untrennbarer Haufen von JS, HTML und CSS die GUI-Schicht einer Webanwendung. Die eigentliche Anwendungslogik spielt sich praktisch nie Clientseitig ab. Und es sieht zugegebenermaßen erst mal so aus, als könnte man (innerhalb der GUI) Design, Struktur und Verhalten trennen, in der Praxis funktioniert das aber nicht. Es funktioniert weitgehend, wenn man es mit Dokumenten zu tun hat, weil HTML dazu entworfen wurde, Dokumente zu strukturieren. GUIs haben aber eine andere und komplexere Struktur und vor allem sehr viel mehr Verhalten.
BTW - hast Du schon mal - bspw. mit MSVS - eine Windows Applikation entwickelt?
Nein, aber ich habe schon andere GUI-Bibliotheken verwendet. Erfahrung habe ich vor allem mit Swing.
In vielen Fällen will man keine zustäzliche Abstraktionsebene für Design haben, schlicht weil das bei GUI oft nicht oder nur mit großem Aufwand zu trennen ist. Wenn man unter "Design" lediglich das Aussehen der GUI-Elemente versteht, stellt Swing dafür aber eine Abstraktionsebene zur Verfügung und viele andere GUI-Systeme tun das auch.
Die Trennung von Struktur und Verhalten ist hingegen etwas, was man normalerweise gar nicht will. Dass das so propagiert wird, fällt mir eigentlich nur im Web- und Javascript-Umfeld auf. Der Schritt der Objektorientierung war ja gerade, die Struktur auf der man arbeitet und ihr Verhalten zusammenzufügen. Wenn man Dokumente mit interaktivität Anreichern will, mag die Trennung noch sinnvoll sein, bei GUI-Programmierung ist das aber nicht so.
Die Trennung zwischen Datenmodell und Darstellung ist natürlich sinnvoll. Die wird aber dadurch erreicht, dass man die gesammte Oberfläche von den Daten und der Anwendungslogik abkoppelt.
Säbelzahnigelchen
Grüße
Daniel
Hi,
ich merke schon, dass es wieder Zeit ist für den Vortrag mit dem o.g. Titel.
Warum sind Webanwendungen cool?
1\.) In diesem kleinen Vortrag wird vorausgesetzt, dass eine Anwendung a) eine Datenbasis, auf der herumgereitet (herumgehühnert) wird, bearbeitet b) diese Datenbasis eine gewisse Komplexität hat und von einem RDBMS verwaltet wird c) Datenzugriffe der Art "CRUDL" (create, read, update, delete, list bzw. SET, GET, LET, DEL und LST) sind bzw. Geschäftsdatenanalysen dienen (wir hätten dann in der Regel zwei Datenhaltungen, da man auf der "transaktionalen" Datenhaltung besser nicht mit Geschäftsanalysen herumreitet, die Geschäftsdatenhaltung ist meist eine Kopie relevanter Teile der "transaktionalen" Datenhaltung) d) einen Sicherheitskontext benötigt, der im RDBMS "abgelegt" wird.
2\.) Der Nutzer sitzt am Browser (wir wollen das den Client nennen) vor einem UI (oder GUI ;) und a) navigiert und b) gibt Datenzugriffe der o.g. Art in Auftrag und c) erhält neue "Seiten" (ein neues UI/GUI). Von wer erhält er dieses? Richtig, vom Server mit dem er per HTTP(S) so zu sagen verbunden (bzw. nicht verbunden ;) ist.
Dieses UI/GUI hat einen Status, den er nicht mit dem Server teilt. Beispielsweise Parameter wie die SitzungsID, bestimmte vorher angeforderte Datensatzmengen ("Trefferlisten", einzelne Datensatzinhalte) und der Navigation dienende Parameter. Handlungen des Nutzers, dienen sie der Navigation oder der Datenbasis, werden entweder rein clientseitig per JavaScript oder serverseitig nach Ausführen eines HTTP(S)-Requests bearbeitet.
3\.) Unter dem o.g. Server ist erst einmal ein Webserver zu verstehen, der HTTP(S)-Requests in Empfang nimmt, also bearbeitet. Der Webserver erhält mit jedem Request Daten. Diese Daten reicht er an eine serverseitig installierte Logik (bspw. Perl, PHP) zur Bearbeitung weiter. Nach erfolgter Bearbeitung sendet der Webserver von o.g. Logik erstellte Daten an den Client zurück.
4\.) Wie sehen die Daten nun aus, die der Client zurückerhält? Exakt, typischerweise HTML-Daten, die wiederum auf andere HTTP(S)-Ressourcen verweisen, die dann clientseitig ggf. nachgeladen werden. Hört sich doch alles recht kompliziert an, was ist daran also cool?
5\.) Cool ist daran u.a., dass die ganze Sache so programmiert sein könnte:
a) Die serverseitige Logik erhält eine Datenzugriffsanforderung und reicht diese an das RDBMS (so genannte stored procedures sollten hier zum Einsatz gelangen) weiter. Dieses prüft die Gültigkeit des Sitzungskontextes und gibt ein XML-Dokument zurück.
b) Für dieses ist ein "Style" präpariert und eine XSLTransformation wird durchgeführt und zu HTML transformierte Daten werden an den Client zurückgegeben.
c) Der Client holt sich ggf. noch das CSS-Dokument, auf das in den o.g. Daten verwiesen worden ist und rendert dann.
6\.) Da die möglichen Datenzugriffsanforderungen bekannt sind, wird folgendes benötigt:
a) eine schlanke serverseitige Logik, die der Navigation dient und Datenzugriffsanforderungen ans RDBMS weiterreicht
b) ein Rudel von Datenzugriffsprozeduren (Namensgebung mit Präfixen wie in Punkt 1 beschrieben wäre nicht verkehrt), das XML-Dokumente zurückgibt und auf
c) Styles (XSLT) verweist, die ebenfalls rudelmässig vorliegen
d) CSS-Dokumente für die Präsentation
e) JavaScript-Code, der entweder gleich in den o.g. Styles liegt, bzw. in ausgelagerten Dokumenten
7\.) Cool ist jetzt - da die Trennung der einzelnen Schichten erarbeitet worden ist - bspw. dass unterschiedliche Personen Teilaufgaben getrennt voneinander bearbeiten können. Getreu dem Motto "Bearbeite voneinander unabhängige Sachen unabhängig voneinander!". Man kann also den "Backie" mit den stored procedures sich vergnügen lassen, ohne dass er sich um weiteres kümmern muss. Er hat sein eigenes in sich geschlossenes System.
Dasselbe gilt in Teilen auch für den Mann (oder Frau ;), der die serverseitige Logik verwaltet. Dieser füllt eine wichtige Rolle aus, könnte auch den Projektchef spielen und fordert mal in eine Richtung ("Backies") mal in eine andere Richtung (frontend) Anpassungen/Weiterentwicklungen an.
Und es gibt natürlich noch den "Frontend-Experten", der Styles entwickelt und JavaScript frickelt (Nur damit es sich reimt ;).
Upps, fast vergessen hätte ich den Designer, der auf alles noch schön "CSS" legt.
Ich könnte jetzt noch ein wenig nachlegen und anmerken, dass es ebenfalls cool ist, dass
- es nur einen Datenclient gibt (den auf dem Webserver)
- relevanter Code immer serverseitig ausgeführt wird
- der nur clientseitig verfügbare Status alles einfacher macht
- keine Installations und Wartungsaufwände (nicht zu unterschätzen!) entstehen
- Einfacheit (das A und O der IT) gegeben ist
- vglw. sehr direkt an den Datenstrukturen gearbeitet wird (vgl. bspw. mit MS Windows-Programmen)
Für Entwickler von "Spezialsoftware" (Spiele, SW mit Grafik-Features, CPU-lastige SW u.s.w.) gilt das alles natürlich auch. Leider müssen diese aber (leider und verständlicherweise) auf "fette" SW zurückgreifen.
MFG
silver Karnickel
Hallo silver,
1.) In diesem kleinen Vortrag wird vorausgesetzt, dass eine Anwendung a) eine Datenbasis, auf der herumgereitet (herumgehühnert) wird, bearbeitet b) diese Datenbasis eine gewisse Komplexität hat und von einem RDBMS verwaltet wird c) Datenzugriffe der Art "CRUDL" (create, read, update, delete, list bzw. SET, GET, LET, DEL und LST) sind bzw. Geschäftsdatenanalysen dienen (wir hätten dann in der Regel zwei Datenhaltungen, da man auf der "transaktionalen" Datenhaltung besser nicht mit Geschäftsanalysen herumreitet, die Geschäftsdatenhaltung ist meist eine Kopie relevanter Teile der "transaktionalen" Datenhaltung) d) einen Sicherheitskontext benötigt, der im RDBMS "abgelegt" wird.
Ja, typische Anforderungen, bei denen Webanwedungen ganz brauchbar sind. Die GUI ist nämlich ziemlich trivial und kümmert sich im wesentlichen "Anfrage erstellen" und "Antwort angucken". Das passt recht gut zu HTML-Formularen und HTTP. Das ganze kann man dann mit JS und CSS noch etwas aufpolieren.
Zentralisierte Anwendungslogik klappt mit Desktopanwendungen natürlich genauso. XSLT und HTML kann man da auch mal einsetzen, wenn man irgend einen Report erzeugen und anzeigen will. Es geht also einfach mehr. So lang man nur GUI-Pradigmen benötigt, die sich gut mit HTML abbilden lassen (Formular ausfüllen, abschicken, antwort angucken), kommt man damit noch ganz gut klar. Braucht man mehr, wird gebastelt.
7.) Cool ist jetzt - da die Trennung der einzelnen Schichten erarbeitet worden ist - bspw. dass unterschiedliche Personen Teilaufgaben getrennt voneinander bearbeiten können.
Software in Schichten und Komponenten aufzutrennen geht immer. Die Tatsache, dass man HTTP dazwischen hat, zwingt ein natürlich zu dieser Trennung. Das Problem ist aber, dass sich die GUI-Schicht einfach schlecht realisieren lässt und dass die Kommunikation zwischen den Schichten über HTTP läuft, was die typische Kommunikation mit Ereignissen schwierig macht.
Und es gibt natürlich noch den "Frontend-Experten", der Styles entwickelt und JavaScript frickelt (Nur damit es sich reimt ;).
Upps, fast vergessen hätte ich den Designer, der auf alles noch schön "CSS" legt.
GUI- und Funktionsschicht lassen sich meist gut trennen, XSLT, JS und CSS werden aber stark aufeinander abgestimmt sein müssen. Das ist alles nicht mehr schön, wenn man über die oben angesprochenen "trivialen" Anforderungen hinaus will. Mit den angesprochenen Technologien, das einigermaßen in den Griff zu bekommen, meinte ich z.B. Java Server Faces oder soweit ich weiß auch ASP.NET. Damit lassen sich Webbassierte GUIs ähnlich aus Komponenten zusammenbauen, wie man das von typischen GUI-Bibliotheken kennt.
- es nur einen Datenclient gibt (den auf dem Webserver)
- relevanter Code immer serverseitig ausgeführt wird
Ja, einfache, zentralisierte Architektur hatte ich ja erwähnt. Stimmt aber nicht wirklich, da das natürlich auch geht, wenn man Clients als Desktopanwendungen realisiert.
- der nur clientseitig verfügbare Status alles einfacher macht
Hä? Bei ein bisschen komplexeren Anwendungen liegt ein Teil des Clientzustands immer auf dem Server (Stichwort "Sessions"), eben weil man kaum Zustand auf dem Client halten kann. Das ist auch etwas, was Webanwendungen umständlich zu implementieren macht.
- keine Installations und Wartungsaufwände (nicht zu unterschätzen!) entstehen
Ja, das ist der Hauptvorteil und vermutlich _der_ Grund, warum Webanwendungen so beliebt sind.
- Einfacheit (das A und O der IT) gegeben ist
Das sehe ich hingegen nicht, Webanwendungen werden oft ziemlich Komplex.
- vglw. sehr direkt an den Datenstrukturen gearbeitet wird (vgl. bspw. mit MS Windows-Programmen)
Was meinst Du damit?
Grüße
Daniel
Hi,
- vglw. sehr direkt an den Datenstrukturen gearbeitet wird (vgl. bspw. mit MS Windows-Programmen)
Was meinst Du damit?
neben der schlanken serverseitigen Logik (und der CSS-Arbeit) sägt man an XML-Bäumen bzw. erweitert man hier und da XML-Bäume. Das ist "minimalistisch", das ist einfach.
- der nur clientseitig verfügbare Status alles einfacher macht
Hä? Bei ein bisschen komplexeren Anwendungen liegt ein Teil des Clientzustands immer auf dem Server (Stichwort "Sessions"), eben weil man kaum Zustand auf dem Client halten kann. Das ist auch etwas, was Webanwendungen umständlich zu implementieren macht.
War wohl ein Schreibfehler, gemeint war wohl, dass wenn der clientseitige Status verloren geht, nicht viel verloren geht.
War alles eher brainstorming, immerhin hats einer gelesen. ;)
Nun überzeugt, dass "Webanwendungen" einfach sind? :)
Viele Grüße!
Mahmoud D'Rselbst