Archiv verlassen und diese Seite im Standarddesign anzeigen : Webseiten programmieren
DocEW
2016-03-17, 22:37:15
Hallo zusammen,
mal eine ganz blöde Frage: Welche Technologie würde man typischerweise wählen, um Webseiten zu erstellen, die im Wesentlichen Daten aus ein paar Datenbank-Tabellen darstellen und damit das Editieren und Hinzufügen von Datensätzen ermöglichen? Da steckt teilweise ein bisschen Logik hinter (wenn der Wert <0 zeig einen roten Rahmen drum, wenn der Knopf gedrückt wird, führe ein bisschen SQL aus, ...), und die Webseiten haben eine hierarchische Struktur, die dynamisch aus der DB kommt. Ansonsten ist es alles harmlos, würde ich sagen. Das ganze im Umfeld eines Großunternehmens.
Hintergrund meiner Frage: Wir haben ein Projekt diesbezüglich mit der IT und es wird SharePoint verwendet (ich glaube eine Web App in C#). Das ganze läuft sehr unbefriedigend, für m. M. n. kleine Änderungen sind immer direkt mehrere Tage fällig. So wie man sich SAP vorstellt. ;) Da frage ich mich langsam, ob die Technologie dafür ungeeignet ist oder die Leute.
Danke für Meinungen!
DocEW
Watson007
2016-03-17, 23:15:30
Java Server Faces, Oracle Apex (für Oracle-Datenbanken), Node.js mit Express etc... oder oldschool mit PHP
Monger
2016-03-18, 03:33:19
Wenn du C# meinst, meinst du vermutlich ASP.NET...
Das alleine ist gar nicht mal so ungewöhnlich. Sich da auf ne HTML Seite ein paar Controls zu ziehen und an ne Datenbank anzubinden, geht recht schnell und simpel.
SharePoint sattelt sich da oben drauf, ist aber ein wahres Monster. Unfassbar komplex... und verdammt teuer. SharePoint war ursprünglich mal eine interne Entwicklung um innerhalb von Microsoft Daten zentral austauschen zu können, bis dann einer ihrer Manager auf die Idee kam, das auf den Markt zu schmeißen. Bis ca. SharePoint 2010 war das entsprechend ein fürchterlicher Verhau. Die neueren Versionen sind deutlich schlanker, und leichter zu administrieren, aber immer noch enorm schwergewichtig.
Kurzum: wunder mich nicht, dass ein Großunternehmen sich so einen Spaß gönnt. Da denkt man sich oft: ich hab bereits die MSDN Lizenzen bezahlt, jetzt will ich sie auch nutzen. Oft genug ist das völliger Overkill.
Aber selbst SharePoint muss nicht per se langsam sein. Wahrscheinlich wollte man ein fertiges Produkt "out of the box", und hat sich dafür das Personal gespart um es richtig einzurichten
ezzemm
2016-03-18, 06:50:00
PHP & MySQL serverseitig, HTML, CSS und Javascript clientseitig.
Ist der Goldstandard würde ich sagen, oder?
Argo Zero
2016-03-18, 07:16:01
Das würde ich auch sagen.
hadez16
2016-03-18, 08:13:17
ASP.NET ist doch dafür recht schick...es muss ja nicht vom Brainbug Sharepoint gemanaged sein.
universaL
2016-03-18, 09:25:42
PHP & MySQL serverseitig, HTML, CSS und Javascript clientseitig.
Ist der Goldstandard würde ich sagen, oder?
zu HTML, CSS, JS gibt es ja kaum Alternativen ;) Wenn man die ganzen Sachen wie CoffeeScript, Typescript, ... zu JS zählt.
Auf dem Server ist als Datenbank finde ich Postgres mindestens auf gleicher Ebene wie MySQL. Und als Implementierungssprache würde ich sagen, hängt es stark davon ab was der jeweilige Programmier schon kann, da schließt sich eigentlich nichts aus: Java, Scala, Haskell, Ruby, Python, Elixir, ...
imho:
(php und goldstandard ;D;D;D;D;D;D) ;-)
Es ist irrelevant welche Technologie verwendet wird. Die Agentur und das beauftragte Entwicklungstem müssen es beherrschen. Darum läuft es Serverseitig meistens auf PHP hinaus. Das hat die weiteste Verbreitung. Ich kenne aber auch Unternehmen bei denen es Ruby ist, oder auch Java.
Also gar nicht drüber Nachdenken und die Werbeagentur damit beauftragen etwas anständiges entwickeln zu lassen in der eigenen CI. Wenn öfters Inhalte geändert werden, dann mit einem CMS. Wenn bestimmte Daten erfasst und dargestellt werden sollen die nicht mit einem typischen CMS gut abgebildet werden können dann braucht es ein speziell entwickeltes Modul dafür. Das sollte aber nicht die Sorge des Unternehmens sein. Sie haben nur Anforderungen, dafür sucht man sich dann einen Dienstleister der diese Anforderungen preiswert und vor allem gut umsetzt. Die Suche nach dem Richtigen Dienstleister übernimmt oft die eigene Werbeagentur (vorrausgesetzt sie hat Ahnung von digitalen Medien).
P.s.: PHP7 ist der Standard. Und es ist alles andere als eine schlechte Wahl. Gerade wenn es um einfache Webseiten und Webanwendungen geht, oder darum das die Wartung selbiger in Zukunft keine Unsummen verschlingen soll weil die Anwendung entweder Closed Source oder auch nur in einer Sprache geschrieben ist deren Entwickler sich das Wissen vergolden lassen. Dazu kommt das die Webseite/Webapp auch irgendwo gehostet werden muss. Bei PHP gibt es gute, preiswerte Hoster wie Sand am Meer.
Ich gehe mal davon aus das es sich nicht um eine Hochverfügbarkeits Anwendung handelt. Sonst würde die Frage hier gar nicht gestellt werden.
Monger
2016-03-18, 11:51:04
Also gar nicht drüber Nachdenken und die Werbeagentur damit beauftragen etwas anständiges entwickeln zu lassen in der eigenen CI. Wenn öfters Inhalte geändert werden, dann mit einem CMS.
Der TS hat das jetzt nicht explizit gesagt, aber wenn ich höre "Simples Frontend auf SharePoint Basis für einen SQL Server in einem Großunternehmen", dann gehe ich von internem Tooling aus. Im eigenen Subnetz ist es ziemlich wurscht ob das Ding schön aussieht, und die Server stellt man üblicherweise im eigenen Serverraum auf. Intern sind oftmals dann ganz andere Technologien verbreitet, als wenn man sich an externe Dienstleister wendet.
Das kann natürlich sein. Ich bin von einem aus dem Internet zugänglichen System ausgegangen auf das auch Kunden zugreifen.
Damit spart man sich dann aber auch nur die Agentur für die CI. Für die Anwendung selbst empfiehlt sich aber weiterhin ein externer Dienstleister, außer man verfügt inhouse über entsprechende Kompetenzen. Daran zweifel ich aber. Problematisch ist nur, das die eigene IT oft allergisch auf externe Dienstleister reagiert. Am liebsten würden die ja alles selbst machen was auch nur entfernt mit ihrem Job zu tun hat.
Gohan
2016-03-18, 16:40:48
Hallo zusammen,
mal eine ganz blöde Frage: Welche Technologie würde man typischerweise wählen, um Webseiten zu erstellen, die im Wesentlichen Daten aus ein paar Datenbank-Tabellen darstellen und damit das Editieren und Hinzufügen von Datensätzen ermöglichen? Da steckt teilweise ein bisschen Logik hinter (wenn der Wert <0 zeig einen roten Rahmen drum, wenn der Knopf gedrückt wird, führe ein bisschen SQL aus, ...), und die Webseiten haben eine hierarchische Struktur, die dynamisch aus der DB kommt. Ansonsten ist es alles harmlos, würde ich sagen. Das ganze im Umfeld eines Großunternehmens.
Hintergrund meiner Frage: Wir haben ein Projekt diesbezüglich mit der IT und es wird SharePoint verwendet (ich glaube eine Web App in C#). Das ganze läuft sehr unbefriedigend, für m. M. n. kleine Änderungen sind immer direkt mehrere Tage fällig. So wie man sich SAP vorstellt. ;) Da frage ich mich langsam, ob die Technologie dafür ungeeignet ist oder die Leute.
Danke für Meinungen!
DocEW
SharePoint ist auch der letzte Dreck wenn es darum geht, eignen Code zu hosten. Mit ein paar Tagen ist zwar übertrieben, trotzdem muss man sehr viel Aufwand betreiben um sicherzustellen, dass das Update eine Lösung für SharePoint reibungslos über die Bühne geht.
SharePoint ist einfach und super für Dinge, die es OOB kann, aber darüber hinaus wird es schnell hässlich.
Da ihr dann scheinbar sowieso eine Microsoft basierte Umgebung hat, würde sich eine einfach CRUD Applikation auf basis von ASP.NET MVC anbieten.
PHP & MySQL serverseitig, HTML, CSS und Javascript clientseitig.
Ist der Goldstandard würde ich sagen, oder?
Bah, geh weg damit. Ist zwar schön, das es überall läuft, aber ich kenne kaum Projekte, die das ganze richtig und gut einsetzen. PHP ist leider eine Pest. Ich will nicht abstreiten, dass man damit auch schönen Code schreiben kann, das meiste was mir aber untergekommen ist war immer der größtmögliche unwartbare Misthaufen an unlesbaren Code den ich kenne. Nur weil vieles damit läuft, heißt es nicht das es gut ist.
z3ck3
2016-03-18, 18:16:35
Nur weil es viel Mist gibt ist das kein Argument gegen die Sprache. Auch in sämtlichen anderen Sprachen wird viel Mist gemacht, man sieht es halt nur seltener, man merkt es nur.
Es ist echt ermüdend das immer wieder und permanent von (studierten) Anwendungsentwicklern und IT Spezis gegen PHP gewettert wird, die vermutlich selbst weder das aktuelle PHP kennen, noch die Frameworks wie Zend, Symfony und Laravel, ORMs wie Doctrine2, Propel oder Eloquent, oder Templateengines wie Twig (etc.). Noch langweiliger wird es wenn PHP als rein funktionale Sprache bezeichnet wird, was dann irgendwie Wissensstand letztes Jahrhundert ist. Und dann gibt es da auch noch sowas wie ReactPHP, was vermutlich nicht mal 99% der PHP Werbeagenturkids auf dem Schirm haben.
Ich habe es anderswo bereits gesagt und es wäre toll wenn das allgemein mal durchdringt: Es spielt keine Rolle in welcher Sprache etwas geschrieben ist, es kommt auf die Entwickler an, die die Sprache einsetzen.
Lokadamus
2016-03-18, 19:25:24
Es ist echt ermüdend das immer wieder und permanent von (studierten) Anwendungsentwicklern und IT Spezis gegen PHP gewettert wird, ... PHP als rein funktionale Sprache bezeichnet wird, was dann irgendwie Wissensstand letztes Jahrhundert ist. ...
Ich habe es anderswo bereits gesagt und es wäre toll wenn das allgemein mal durchdringt: Es spielt keine Rolle in welcher Sprache etwas geschrieben ist, es kommt auf die Entwickler an, die die Sprache einsetzen.Ich glaube, das dies das Hauptproblem ist. Die Änderungen und Möglichkeiten, die sich durch ein paar Veränderungen ergeben, wollen die meisten nicht sehen.
Es gibt gute Gründe weiter auf php zu setzen wenn bereits eine halbwegs entspaghettifizierte Anwendung läuft. Aber in den letzten Jahren haben sich die Alternativen deutlich schneller entwickelt. Auf grüner Wiese ein (nicht triviales) Projekt mit PHP anzufangen macht wirklich nur Sinn wenn schon einiges an Erfahrung im Team vorhanden ist, die auch taugt.
Andererseits schaffen es geübte Yakrasierer mit "Not invented here"-Syndrom Projekte in jeder Sprache gegen die Wand zu fahren. Php macht es ihnen halt nur etwas leichter.
DocEW
2016-03-18, 22:09:26
Vielen Dank für die zahlreichen Antworten, das war schonmal sehr hilfreich! :up:
Der TS hat das jetzt nicht explizit gesagt, aber wenn ich höre "Simples Frontend auf SharePoint Basis für einen SQL Server in einem Großunternehmen", dann gehe ich von internem Tooling aus. Im eigenen Subnetz ist es ziemlich wurscht ob das Ding schön aussieht, und die Server stellt man üblicherweise im eigenen Serverraum auf. Intern sind oftmals dann ganz andere Technologien verbreitet, als wenn man sich an externe Dienstleister wendet.
Ja, ist für den internen Gebrauch. Soll aber trotzdem hübsch werden, auch interne Kunden sind wichtig. :) Und ja, es ist ein externer Dienstleister.
SharePoint ist auch der letzte Dreck wenn es darum geht, eignen Code zu hosten. Mit ein paar Tagen ist zwar übertrieben, trotzdem muss man sehr viel Aufwand betreiben um sicherzustellen, dass das Update eine Lösung für SharePoint reibungslos über die Bühne geht.
SharePoint ist einfach und super für Dinge, die es OOB kann, aber darüber hinaus wird es schnell hässlich.
Da ihr dann scheinbar sowieso eine Microsoft basierte Umgebung hat, würde sich eine einfach CRUD Applikation auf basis von ASP.NET MVC anbieten.
Danke, dass es da innerhalb von SharePoint noch solche Unterschiede gibt, war mir nicht klar! Kann man bei der von dir vorgeschlagenen Lösung auch Credentials durchreichen?
Monger
2016-03-19, 02:57:01
Danke, dass es da innerhalb von SharePoint noch solche Unterschiede gibt, war mir nicht klar! Kann man bei der von dir vorgeschlagenen Lösung auch Credentials durchreichen?
Ich vermute du meinst eine Authentifizierung via Active Directory? Unterstützung fürs LDAP Protokoll findet man in fast allen Umgebungen - aber in ASP.NET ist das quasi Standard. Ist eigentlich ziemlich trivial. Microsoft geht selbstverständlich davon aus dass Microsoftprodukte in einer Microsoftumgebung laufen.
Exxtreme
2016-03-19, 16:42:48
Man sollte aber eine Sache bedenken: wenn dieses simple Projekt gut funktioniert dann ist die Wahrscheinlichkeit gering, dass es klein und simpel bleibt. Weil dann kommen die Sonderwünsche aus den Abteilungen. :D Ich habe sowas schon hinter mir. Aus einem kleinen Access-Frontend mit DB-Anbindung ist ein halbes ERP-System geworden. :D
Da sollte man auch Technologien wählen, die auch für heftigere Anforderungen taugen.
Gohan
2016-03-19, 16:56:04
Danke, dass es da innerhalb von SharePoint noch solche Unterschiede gibt, war mir nicht klar! Kann man bei der von dir vorgeschlagenen Lösung auch Credentials durchreichen?
Klar, nennt sich beim IIS (Internet Information Serivce) Windows Authentication. Du kannst auch einzelne URLs noch auf bestimmte User/Rollen/Gruppen einschränken, Quick&Dirty über die Web.Config oder im Code direkt.
Ich habe schon einige SharePoint-Lösungen entwickelt, Spaß ist was anderes und man fragt sich echt immer wieder, was die Leute hinter SharePoint sich bei manchen Entscheidungen gedacht haben.
Da sollte man auch Technologien wählen, die auch für heftigere Anforderungen taugen.
Denke schon, das ASP.NET MVC dem gewachsen ist ;) Man muss halt nur die Architektur seiner Applikation entsprechend auslegen. Das mache ich eigentlich mittlerweile immer, auch wenn es nur heißt, mach mal eben.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.