MiddleWare über TCP/IP zwischen App und DB

Edenus

Hallo,

ich habe ein Programm geschrieben, das direkte Verbindungen zur DB mittels ODBC aufbaut. Doch ich höre oft genug das dies nicht üblich sei. Man würde immer so genannte MiddleWares erstellen. Also ein Programm das zwischen Client und Server agiert. Die Verbindung zwischen Client und MiddleWare läuft nur über TCP/IP und MiddleWare DB dann natürlich ODBC. Das sei stabiler, da die Clients hin und wieder abstürzen können und TCP/IP Verbindungen leichter und stabiler sind.

Hat jemand ne Ahnung wo ich für MiddleWare Lösungen in (möglichst) C# Infos im Netz finden kann? SourceCode wäre hilfreich, aber Dokus als Hilfestellung oder grobe Tutorials wären auch toll.

Danke und Gruss

Edenus schrieb:

Hallo,

ich habe ein Programm geschrieben, das direkte Verbindungen zur DB mittels ODBC aufbaut. Doch ich höre oft genug das dies nicht üblich sei. Man würde immer so genannte MiddleWares erstellen. Also ein Programm das zwischen Client und Server agiert. Die Verbindung zwischen Client und MiddleWare läuft nur über TCP/IP und MiddleWare DB dann natürlich ODBC. Das sei stabiler, da die Clients hin und wieder abstürzen können und TCP/IP Verbindungen leichter und stabiler sind.

Hat jemand ne Ahnung wo ich für MiddleWare Lösungen in (möglichst) C# Infos im Netz finden kann? SourceCode wäre hilfreich, aber Dokus als Hilfestellung oder grobe Tutorials wären auch toll.

Danke und Gruss

Nimm einfach den OLEDB-Adapter im .NET.
Anstatt die DB per Assistenten statich zu verlinken bau den Code so auf dsa
dsa OleDbConnection-Onbjekt dynamisch mit alle Informationen zur Datenbankanbindung gefüttert wird!
Wenn Du nicht weisst was ich mit Dynamisch meine mach nen Projekt auf wo Du die Connection per Assistent zusammenbaust und dann guck Dir den Code an den der Quelltextgenerator bei der Connetion generiert.

Client <------> Middleware <------> Db-Server hmmm weiss jetzt nicht wie

ich das verstehen soll und warum das unbedingt eine glücklichere Lösung sein soll. Wenn das Netzwerk zusammenbricht gehen eh nur noch DB's die lokal bei den Clients liegen. Was brauche ich eine Middleware wüsste nicht warum.

OleDb im .NET ist ne feine Sache. In der 3er-Konstellation ist eine Sache mehr drin die abstuerzen kann. Zudem arbeitet OleDb lokal als auch Netzuebergreifend! Weiss also nicht was Du mit TCP/IP meinst dieses Protokoll
ist gut versteckt in den OleDb-Kram des .NET eingestrikt schon drin.

MicrosoftPress hat tolle Speialbücher zu diesem Thema.
Was brauche ich da noch ne Middleware?

Gruss sclearscreen

Kannst Dir dann noch ein Klasse fuer Datenbankanbindung selbst bauen die mögliche DB's berücksichtigt und fuer jede DB das entsprechende Connection-Objekt liefert.

Das einzige was sich immer jenach DB unterscheidet ist der Connection-String
des Objektes OleDbConnection.

jenachdem welche DB ob global/lokal sieht der Connectionstring

this.oleDbConnection1 = new System.Data.OleDb.OleDbConnection();
			// 
			// oleDbConnection1
			// 
			this.oleDbConnection1.ConnectionString = @"Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Registry Path=;Jet OLEDB:Database Locking Mode=1;Data Source=""c:\db.mdb"";Jet OLEDB:Engine Type=5;Provider=""Microsoft.Jet.OLEDB.4.0"";Jet OLEDB:System database=;Jet OLEDB:SFP=False;persist security info=False;Extended Properties=;Mode=Share Deny None;Jet OLEDB:Encrypt Database=False;Jet OLEDB:Create System Database=False;Jet OLEDB:Don't Copy Locale on Compact=False;Jet OLEDB:Compact Without Replica Repair=False;User ID=Admin;Jet OLEDB:Global Bulk Transactions=1";

eben anders aus anhand diese String weiss der Adapter dann was ermachen muss:
-DB SQL-Server ansprechen (das läuft ja dann ueber Netzwerkprotokolle auf niedriger Ebene)
-lokale DB auf eigenem Rechner anmachen

obiges Bsp.: ist fuer eine lokale DB

Deine unmittelbar nutzbare Middleware wäre demnach alles was das Framework rund um OleDb bereitstellt.

Fuer spezielle DB MySQL undoder ORACLE gibts oder sollte es imm Netzt entsprechend Downloads geben die sich ins .NET intergrieren. Ich habe ine fuer MySQL. Das ganze Gedöns darin funktioniert wie bei den DB-Techniken die das Framework schon mitbringt. Musst also nichtmal gross in der Handhabung umlernen.

Edenus

Das sagen viele so.
Es heisst immer, das es professionell mit einer MIddleWare gelöst wird.

Weil direkte DB Verbindungen instabiler und schwieriger zum Wiederherstellen (nach Absturz) sind.

Daher die MiddleWare, da benutzt man eine einfach TCP/IP Verbindung. Die DB Results kommen dann in XML-Binary Form über den Socket und werden z.B. auf dem Client in einem DataGrid ausgegeben.

Ich finde diese Lösung super. Der Client hat dann nur eine simple TCPIP Verbindung, aber über diese wird alles abgeklärt. Sowohl die SQL Queries als auch Befehle zum Ausdrucken von Reports zum Beispiel.

Ich könnte natürlich jetzt einfach loselegen mit dem Programmieren, aber vielleicht gibts da bekannte Standardtechniken was es mir einfacher macht.

Edenus schrieb:

Das sagen viele so.
Es heisst immer, das es professionell mit einer MIddleWare gelöst wird.

Weil direkte DB Verbindungen instabiler und schwieriger zum Wiederherstellen (nach Absturz) sind.

Daher die MiddleWare, da benutzt man eine einfach TCP/IP Verbindung. Die DB Results kommen dann in XML-Binary Form über den Socket und werden z.B. auf dem Client in einem DataGrid ausgegeben.

Ich finde diese Lösung super. Der Client hat dann nur eine simple TCPIP Verbindung, aber über diese wird alles abgeklärt. Sowohl die SQL Queries als auch Befehle zum Ausdrucken von Reports zum Beispiel.

Ich könnte natürlich jetzt einfach loselegen mit dem Programmieren, aber vielleicht gibts da bekannte Standardtechniken was es mir einfacher macht.

Bei dem Oledb-Kram bekommst D ein DataSet zurueck damit kommst Du durch Netzt sogar durch ne Firewall weil es auf http aufsetzt.
Das DataSet ist faktisch XML weil es mit XML arbeiten/umgehen kann
Guck Dir das DataSet in der MSDN mal an.

Irgendwie vermute ich da Du ja schreibst bevor ich mit dem programmieren solcher Sachen Anfange....

Probieren/Ansehen der/die Technologiebeispiele der MSDN und Du wirst sehen
das es das ist was man getrost verwenden kann.

Da ich nicht implemetierer des Framework in punkto DB bin

aber schon mit Oldb und DB rumgetüttelt habe denke ich das es genau das ist was Du suchst.

damit funszt alles:

-"stored procedures" ausführen
-Transaktion aufm SQL-Server aufmachen
-SQL-Krams

alles

Also Du musst schon selbst was ausprobieren das Middleware besser ist hat man Dir auch nur in den Mund gelegt!
Kann mir auch kaum vorstellen das es sowas billig zum ausprobieren im Netz gibt. Ausserdem intern nutzt die Middleware auch nur althergebrachte
Datenbank-Connectivity, wohl kaum "feuchte Seile". Sorry musste sein

Solltest Du eine MCAD/MCSD-Prüfung mal machen wird Microsoft bestimmt
keine Fragen zu Datenbankkram drinhaben die auf externe Middleware aufsetzen.

"profesionell" was sagt das schon ueber Middleware aus oder ueber Code den
Du auf Basis des Framework aufsetzt.

Diese Middleware ist meines Erachtens nur ein Flaschenhals mehr mit einem neuen
Faktor Leistungseinbuße weil der SQL-Server der als 3er kommt arbeitet dadurch auch nicht schneller.

Edenus schrieb:

Das sagen viele so.

Weil direkte DB Verbindungen instabiler und schwieriger zum Wiederherstellen (nach Absturz) sind.

Beim Abfragen arbeitest Du beim DataSet immer mit einer Kopie der Dtaen aus Der DB. Deshalb spielt diese Aussage von Dir keine Rolle.

Genauso ein Transaktion auf einem SQL-Server wird in einem Transaktionsprotokoll mit gloggt. Wird diese aus eineim unerfindlichen Grund
unterbrochen vor abschluss arbeitet der SQL-Server so das er den Datenzustand vor der Transaktion wiederherstellt. Wie man sieht ist an vieles schon gedacht!

Ich glaube Du musst Dir unbedingt die Technologiebeispiel durcharbeiten und ausprobieren und verstehen.

Das einzige was ich mir bei einer Middleware vorstellen kann aber auch nur wenn diese kompetent administeriert wird ist. Das SQL-Querys die auf DB's abzielen die auf dem Server nicht existieren garnichterst zum Server durchgereicht werden. Aber das ist bestimmt kein ausreichender Grund sich so eine bestimmt nicht billige Software zu leisten.
Das ist höchsten wie das 100ste Medikament um nicht dick zu werden.

Noodles

Wenn Du .NET 2.0 verwendest kannst Du auch mal System.Transactions.TransactionScope ansehen.
Willst Du direkt mit Sockets arbeiten oder reicht vlt. auch .NET Remoting. Evtl. kannst Du Dir auch mal WCF ( Windows Communication Foundation ) ansehen.