Laden...
Avatar #avatar-2834.jpg
Rainbird myCSharp.de - Experte
Fachinformatiker (AE) Mauer Dabei seit 28.05.2005 3.728 Beiträge
Benutzerbeschreibung
Ich mag Tee lieber als Kaffee.

Forenbeiträge von Rainbird Ingesamt 3.728 Beiträge

25.05.2009 - 10:17 Uhr

Hallo esskar,

ich weiss zwar nicht, mit welcher Technologie die Kommunikation zwischen Client und Server bei Dir implementiert ist, aber im Falle von WCF gibt es das was fertiges eingebautes: Service Throttling.

Es handelt sich dabei um Konfigurationseinstellungen, mit denen Du Dienstzugriffe auf ein gewünschtes Niveau drosseln kannst. Wie das geht, findest Du hier: http://www.codeproject.com/KB/WCF/WCFThrottling.aspx

25.05.2009 - 07:07 Uhr

Hallo antoschka,

WCF-Dienste kannst Du von COM-Anwendungen aus über Moniker ansprechen. Wie das funktioniert, findest Du hier: http://msdn.microsoft.com/de-de/library/ms752245.aspx
http://geekswithblogs.net/cicorias/archive/2007/08/28/Consuming-WCF-Services-from-COM-using-C.aspx

24.05.2009 - 16:58 Uhr

Wenns nicht geht muss ich wohl alles schicken - aber da ist die Serverlast halt extrem hoch - wie im Post oben beschrieben

Du schickst doch nur die Datensätze zurück, die dem angegebenen Filter entsprechen. Die Last auf dem Server ist genauso hoch, ob Du alles in einem Stück sendest, oder das Stück für Stück über einen Stream sendest. Nur dass der Stream aufwendiger ist und mehr Overhead erzeugt.

Dein Argument, dass Streaming die Serverlast verringert, ist damit Null und Nichtig! Der Client muss vermutlich eh warten, bis alle Datensätze gestreamt wurden, bevor er weitermachen kann. Wenn Du z.B. ein 4 GB großes Video vom Server abrufst und der Client dieses abspielen soll, ist Streaming z.B. sinnvoll, da der Client mit der Wiedergabe des Videos sofort beginnen kann. Weniger Last hat der Server desalb trotzdem nicht. Es wäre nur blöd, wenn man drei Stunden warten müsste, bis die Wiedergabe des Films startet. Bei Deinen Datensätzen ist das vermutliuch nicht der Fall. Um wie viele Datensätze handelt es sich durchschnittlich?

19.05.2009 - 07:36 Uhr

Hallo mydani,

ich würde die Steuerfunktionen (also jene, die von den Kommandozeilentools konsumiert werden sollen) in eine Schnittstelle packen. Diese in eine sperate Assembly (Contract-Assembly) und dann würde ich die Steuerfunktionen mittels Remoting über einen IPC-Kanal (verwendet intern Named-Pipes) veröffentlichen. Die Consolenanwendung kann sich für die veröffentlichten Objekte mittes Activator Proxies für den entfernten Zugriff erzeugen.

Die Windows.Forms-Anwendung kann so in einer eigenen Anwendungsdomäne laufen und kann von anderen Anwendungsdomänen oder Prozessen aus (wenn man noch einen TCP-Kanal zusätzlich konfiguriert auch übers LAN) ferngesteuert werden.

Nachteil dieses Ansatzes ist, dass für die Remoting-Kommunikation ein gewisser Overhead anfällt. Der Vorteil ist, dass die Forms-Anwendung als Server eingesetzt werden kann, der auch mehrere Clients bedinen kann. Ob das für Deinen Anwendungsfall relvant ist, weiss ich natürlich nicht.
Auf jeden Fall musst Du Dich dann mit Threads nur noch in ganz begrenzem Umfang herumschlagen. Ausgehend von einer Singleton-Aktivierung, würde Remoting für jeden Clientzugriff einen Thread erzeugen, um diesen Abzuarbeiten. Invoke ist dann Dein Freund, um das ActiveX-Control zu manipulieren.

19.05.2009 - 07:17 Uhr

Wie hast du das gelöst? Schiebst du bei der Warenwirtschaft alle Ergebnisse durch eine Funktion?

Ja, genau. Schon alleine wegen der Transaktionen wäre es schlecht, alles in kleinen Stücken zu übertragen. In verteilten Anwendungen heißt es: Klotzen, nicht kleckern!

Also die Anzahl der entfernten Zugriffe gering halten und die Daten möglichst am Stück übertragen. Im Falle einer Warenwirtschaft heißt das z.B. dass man ein komplettes DataSet mit Kopfdatensatz und allen Positionen auf einmal überträgt, wenn man einen Auftrag einbuchen will.

Ich habe in meinem n-Tier Beispiel Remoting verwendet. Da gibt es zum Glück keine Begrenzungen für Nachrichtengröße etc. Da Du WCF verwendest, solltest Du wirklich die Standardwerte anpassen. Das ist nichts verwerfliches. Die Standardwerte sind deshalb so restriktiv gesetzt, um die Angriffsfläche für WCF-Dienste, die übers Internet erreichbar sind, gering zu halten. Im Falle einer Warenwirtschaft, würdest Du aber eh niemals unverschlüsselt mit HTTP ubers Internet gehen. Deshalb kannst Du die Beschränkung der Nachrichtengröße in diesem Fall bedenkenlos abschalten.

18.05.2009 - 11:24 Uhr

Ich benutze den OleDb Provider weil ich später andere Datenbanken anbinden möchte.

Wenn Du alle Connections und Commands über eine ADO.NET-Providerfactory erzeugst (wie FZelle bereits vorgeschlagen hat), dann kannst Du den kompletten Provider per App.config-Einstellungen auswechseln. Wie sowas aussehen kann, findest Du hier:
Providerunabhängige Datenzugriffskomponente

18.05.2009 - 09:45 Uhr

Hallo winmike,

ich würde eher die Standardwerte (z.B. das eine SOAP-Nachricht nicht größer als 64 KB sein darf) für Deine Anwendung anpassen. Das geht ganz einfach in der App.config.

15.05.2009 - 08:12 Uhr

Hallo Schrankwand,

sowas kannst Du auch sehr gut mit WCF machen. Das hat gegenüber Socket-Programmierung (TcpListener) den Vorteil, dass Du nicht alles selber schreiben musst. WCF ermöglicht Dir entfernte Methodenaufrufe übers LAN oder über das Internet.

14.05.2009 - 09:09 Uhr

Hallo Abt,

Shared AddIns sind nicht die stabilsten. Hat es einen besonderen Grund, warum Du ein Shared Add-In baust, statt VSTO zu verwenden?
Ich empfehle Dir, Outlook Add-Ins mit VSTO zu erstellen. Da hast Du mehr Unterstützung in Visual Studio und VSTO Add-Ins sind im Allgemeinen robuster.

Falls Du VSTO nicht einsetzen kannst, musst Du Dein Problem natürlich trotzdem lösen. Laufen noch andere Add-Ins bei Dir in Outlook?
Hat sich die Outlook-Instanz korrekt in die Running Object Table eingetragen? Folgendes Snippet hilft Dir, das zu prüfen: Laufende COM-Objekte abfragen

14.05.2009 - 08:23 Uhr

Hallo daprodigy,

offenbar wird das Datumsformat nicht richtig erkannt. Da wirst Du IXmlSerializable manuell für die Klasse implementieren müssen.

Hier hatte jemand ein ähnliches Problem: http://social.msdn.microsoft.com/Forums/en-US/asmxandxml/thread/45dd2466-71ab-4c02-aa3d-988a49a44639

14.05.2009 - 08:05 Uhr

Hallo korny,

wenn ich Dich richtig verstanden habe, möchtest Du in der ersten ComboBox statt*Software 1 *Software 2 *Software 1 *Software 1 *Software 2

folgendes in der Dropdownliste haben:*Software 1 *Software 2

Im SQL Server würde man sowas durch eine GROUP BY Klausel ereichen. Mit einem DataSet bzw. einer DataTable wird das nicht klappen. Auch über BindingSource oder DataView nicht. Da kann man zwar Filtern und Sortieren aber leider nicht Gruppieren.

Das hat aber auch seinen Grund. DataTables sind dafür ausgelegt, dass auch Daten geändert, neu angelegt und gelöscht werden können. Bei gruppierten Daten wäre das nicht mehr möglich.

Du hast zwei Möglichkeiten:*Eine zusätzliche DataTable erzeugen, in die Du die gruppierten Daten von Hand einfügst *Die ComboBox mit AddItem manuell befüllen

14.05.2009 - 07:56 Uhr

Hallo Stefan,

DataSets können im Speicher sehr groß werden. Dispose gibt die verwendeten Ressourcen für den Müllsammler zum abräumen frei, so dass der Arbeitsspeicher schnell wieder für andere Daten zur Verfügung steht. Du solltest Dispose deshalb aufrufen. Vor allem in Formularen, wenn Datenbindung zum Einsatz kommt.

13.05.2009 - 10:40 Uhr

Hallo GammaKlaus,

der Namensraum Microsoft.Office.Core ist in der Assembly Office.dll definiert. Diese ist im PIA-Verzeichnis der jeweiligen Office-Version zu finden. Du musst also die PIAs für Deine Office-version installiert haben. Wenn Du VSTO installiert hast, liegen die PIA-Assemblies vermutlich unterhalb des VSTO-verzeichnisses.

13.05.2009 - 10:30 Uhr

Hallo Andreas,

wenn Excel eine Arbeitsmappe lädt, dann trägt sich die Excel-Instanz mit dem Dateinamen der Arbeitsmappe (also die xls-Datei) in die Running Object Table ein. In der Running Object Table stehen alle laufenden COM-Server der aktuellen Windows-Sitzung.

Mit folgendem Snippet, kannst Du die richtige Excel-Instanz (also ach dann wenn noch andere Excel-Instanzen zusätzlich geöffnet sind) zuverlässig abgreifen: Laufende COM-Objekte abfragen

13.05.2009 - 08:29 Uhr

Da muss ich svenson voll zustimmen. MSMQ ist für sowas sehr gut geeignet und wird von WCF auch gut unterstützt.

13.05.2009 - 08:24 Uhr

Es ist jedoch so, dass ich nicht mit "fremden" Clients Kommunizieren muss. Server (Webservice) wie auch Client-App sind sozusagen "Proprietär" in unseren Händen.

Warum dann überhaupt SOAP? SOAP ist langsam. Binäre TCP-Kommunikation ist wesentlich schneller und lässt sich ebensogut mit WCF absichern.

12.05.2009 - 09:20 Uhr

Hehe, ich würde sagen, dass wir - IT'ler(innen) - viel zu realistisch sind, dass wir uns mit der Träumerei - und somit die Grundvoraussetzung fürs Dichten - beschäftigen mögen.

Das kann man nicht generell so sagen. Als Hobby-Rollenspielentwickler - der sich auch gerne phantastische Geschichten zusammenträumt - muss ich da widersprechen.

12.05.2009 - 09:15 Uhr

Hallo marcelws,

wenn Du von Prozessen sprichst, was meinst Du damit? Betriebssystem-Prozesse im Sinne von EXE-Dateien? Geschäftsprozesse? Methoden die einen bestimmten Prozess implementieren?

Diese anderen 2 Prozesse, was machen die genau und wie werden sie angesprochen.

Wartet der Webservice bis alles importiert ist und sendet dann eine Antwortnachricht an den Client zurück, oder funktioniert das genaze Asynchron (mit Callbacks etc.)?

12.05.2009 - 09:04 Uhr

Hallo kaepten,

wenn Du Interoperanel sein musst (weil Du z.B. auch mit PHP zugreifen musst), solltest Du die Sicherheit auf Transportebene implementieren. Das verwendete Protokoll heißt SSL bzw. TLS (TLS ist nicht auf HTTP beschränkt, SSL schon). Die Verschlüsselung erfolgt dabei über X.509-Zertifikate. Bei SSL verschlüsselten HTTP-Verbindungen spricht man von HTTPS.

SSL/TLS beherrscht sowohl Apache als auch IIS und kann von PHP und von .NET Anwendungen verwendet werden. Für WCF würde das konkret heißen: BasicHttpBinding + aktivierte Transportsicherheit.

Hier solltest Du alles nötige darüber nachlesen können: http://msdn.microsoft.com/de-de/library/ms733043.aspx

Wenn Du Dich in einer Microsoft-Monokultur bewegst, kannst Du auch Windows-Sicherheit verwenden. Das setzt allerdings vorraus, dass alle beteiligten Teil der selben Active Directory-Domänengesamtstruktur sind und die nötigen Vertrauensstellungen bestehen.

11.05.2009 - 23:10 Uhr

Out? In? Wer bestimmt das?
Warum soll man sich um dergleichen Statistiken über Durchschnittsmenschen kümmern?

Bei Dingen, die man mit vielen Menschen zusammen macht, hat In oder Out ja wenigstens ein Gewicht, da bei In-Aktivitäten eher andere Leute mitmachen, aber sachen wie Dichten, was man eh alleine tut, spielt das wirklich keine Rolle.

11.05.2009 - 23:03 Uhr

Hallo noxe,

folgende Seite sollte Dir da weiterhelfen: http://www.msxfaq.de/code/storesink.htm

11.05.2009 - 22:59 Uhr

Hallo mipa_acc,

ein Word-Fenster kann immer nur ein Dokument anzeigen. Du musst deshalb vorher das momentane Dokument (egal ob das leer ist und Unbenannt1 heißt) entladen. Wenn Du ActiveDocument.Close vorher aufrufst, wird Dein Dokument auch ins aktuelle Fenster geladen.

11.05.2009 - 22:49 Uhr

Hallo Luigi,

das mit dem Thread.Sleep ist Müll! Du solltest stattdessen das Drucken nicht im Hintergrund laufen lassen. Das geht genaz einfach:


docApp = new Word.ApplicationClass();
printer = docApp.ActivePrinter;
docApp.ActivePrinter = "FreePDF XP";
docApp.Documents.Add(ref ofileName, ref dummy, ref oint, ref dummy);

// Hintergrunddruck abschalten
bool backgroundPrinting=false;

// Drucken (Die Methode wartet nun, bis alle Daten an den Spooler übergeben wurden)
docApp.PrintOut(ref backgroundPrinting, ref dummy, ref dummy, ref opsName, ref dummy,
ref dummy, ref dummy, ref dummy, ref dummy, ref opages, ref otrue,
ref dummy, ref dummy, ref dummy, ref dummy, ref dummy, ref dummy,
ref dummy, ref dummy);

docApp.ActivePrinter = printer;
docApp.Quit(ref obool, ref dummy, ref dummy);

11.05.2009 - 22:43 Uhr

Hallo Haggy,

wie erzeugst Du denn genau die Outlook-Instanz in Deinem Code?
Verwendest Du PIAs?
Verwendest Du VSTO?

Braucht Outlook vielleicht seit SP2 etwas länger zum Starten, weshalb es länger dauert, bis Outlook.Application in der Running Object Table eingetragen wird? Nur eine Vermutung

11.05.2009 - 22:35 Uhr

Versuche ich allerdings die Formel händisch so in die Zelle einzutragen dann fliegt er mir auf die Nase... per FormulaR1C1 aus C# heraus (valueRange.FormulaR1C1 = =SUM(R[-6]C:R[-1]C) ; ohne Maskierung mit " weil er das Ganze sonst nur als STRING einträgt) mit der Meldung "Ausnahme von HRESULT: 0x800A03EC"?

Hä?! Der C#-Compiler kann mit einem Konstrukt wie diesem nix anfangen:


// Das klappt so nicht!
valueRange.FormulaR1C1 = =SUM(R[-6]C:R[-1]C;

Du musst das als String zuweisen. Das Objektmodell von Excel ist IMMER DAS GLEICHE! Es geht deshalb in C# genauso wie in VBA. Wenn es in VBA mit String-Zuweisung geht, dann tut das auch in C# so.

11.05.2009 - 22:17 Uhr

Hallo BrokeMan,

neue E-Mails in Öffentlichen Ordnern werden dummerweise als Objekte der Nachrichtenklasse IPM.Post gespeichert, statt als IPM.Note (wie es eigentlich sein sollte).

Diesen "Bug" kann man aber seit Service Pack 1 (Exchange 2003) einfach beheben: http://support.microsoft.com/kb/817809

Wenn man die Einstellung laut dem obigen KB-Artikel in der Registry ändert, kommen E-Mails an öffnetliche Ordner als ganz normale IPM.Note-Mails (Outlook-Klasse MainItem) an. Allerdings werden die alten nicht konvertiert.

IPM.Post-Nachrichten kannst Du brigens bei Outlook in PostItem-Objekte casten.

11.05.2009 - 22:06 Uhr

Ich habe selber noch nie mit Durable Services gearbeitet. Aber hier ist ein ganz gutes Beispiel: http://geekswithblogs.net/claeyskurt/archive/2008/09/01/wcf_durable_services_explained.aspx

Wenn ich das richtig verstanden habe, musst Du Dich selber darum kümmern, dass die InstanceID clientseitig in den Context kommt. Du musst ja davon ausgehen, dass der Client zwischen zwei Aufrufen nicht der Selbe ist. Möglicherweise wurde die Anwendung sogar inzwischen neu gestartet. Deshalb verwendet man ja Durable Services.

10.05.2009 - 23:57 Uhr

Hallo winmike,

was heißt "... bleibt hängen.." ? Gibt es eine Ausnahme (wenn ja, welche)?

Generell solltest Du bei entfernten Methodenaufrufen vorzugsweise an Aufrufen sparen. Also statt z.B. auf dem Client 50 x die SaveAddress-Operation übers Netzwerk aufzurufen, wenn Du 50 Adressen über einen Addessendienst anlegen willst, solltest Du alle 50 Adressen in eine Request-Message packen und diese an einem Stück an die Methode SaveAddresses senden. Dann hast Du nur 1 x Netzwerk-Overhead!

Du solltest Proxies auf dem Client möglichst nicht jedes Mal schließen, das sie recht teuer beim Erzeugen sind.

10.05.2009 - 00:08 Uhr

Was spricht denn gegen die Vorgehensweise die strenge Kopplung zum Objekt, was der OR-Mapper erzeugt zu lösen und seinen eigenen View-State einzubauen ?

Der hohe Aufwand und die unnötige Komplexität, die in den Client hinengebracht wird. Das ist nur dann zu rechtfertigen, wenn woanders dadurch mehr Aufwand reduziert wird. Wenn die Applikation z.B. viele verschiedene RDBMS unterstützen muss, reduziert die Implementierung mit dem Entity Framework und ESQL den Aufwand z.B. extrem. Dann kann man sich auch mehr Arbeit auf dem Client machen. Trotzdem zahlt man einen hohen Preis. Die hohe Abstraktion frisst Ressourcen und die vom EF automatisch generierten SQL-Statements sind u.U. nicht optimal.

Warum clientseitig ein Change Tracking für Objekte implementieren (was, wenn man es gut machen will, keine triviale Angelegenheit ist!), wenn das .NET Framework bereits eine ausgereifte Technologie enthält, die das alles schon kann (ADO.NET)?
Ein typisiertes DataSet oder untypisierted DataSet ist genauso entkoppelt, wie eine Objektliste. Es sind keine Sessions o.ä. auf dem Server nötig. Automatisches Mapping von SQL auf den Zieldialekt bietet normales ADO.NET zwar nicht aber trotzdem eine gute Unterstützung für mehrere Datenbanken ohne Neukompilierung der Anwendung. Wie sowas aussehen kann, siehst Du hier: Providerunabhängige Datenzugriffskomponente

09.05.2009 - 23:42 Uhr

Ich hab mich nochmal schlau gemacht. An WebDAV hat sich zwar nichts geändert, aber Microsoft hat die WebDAV-Unterstützung für OWA in Exchange 2007 einfach komplett abgeschaltet.

Note: There is no API for working with OWA settings and WebDAV cannot be used in any supported way in this area. Same is true for the RTM version. Applications which used WebDAV to work with OWA settings will likely fail under the RTM and SP1 versions of Exchange SP1.

Zitat aus:
>

Trotzdem sollte es möglich sein, mit WebDAV zuzugreifen. Möglicherweise muss man das aber als zuätzliches Virtuelles Verzeichnis aufsetzen (Bim 2003er ging das über das Standard-Verzeichnis, welches auch OWA benutzt).

Statt über WebDAV geht das beim Exchange 2007 nun auch über SOAP-Webservices. Das ist für C#-Entwickler wesentlich einfacher und bietet auch mehr Funktionen an. Einfach Webverweis zufügen und loslegen! Hier ist ein Beispiel, wie man damit auf Kalendereinträge zugreift: http://msdn.microsoft.com/en-us/library/bb738399.aspx

Ob die Umstellung der Applikation viel oder wenig Aufwand erfordert, hängt vom Umfang und der Komplexität der Applikation ab. Das kann ich deshalb leider nicht beurteilen.

08.05.2009 - 00:29 Uhr

Hallo meisteralex,

WCF ist dafür gut geeignet. Du solltest Dir nur Gedanken machen, ob Du eine reine .NET Anwendungen bauen willst, oder ob die Dienste auf den Applikationsservern auch Interoperabel sein müssen (weil z.B. auch Java-Clients zugreifen müssen/wollen/sollen). Für den Ersten Fall kannst Du mit dem net.tcp-Binding und einer ChannelFactory ähnlich wie Remoting arbeiten. Für den zweiten Fall solltest Du Dich über MessageContracts und WS-* Spezifikationen schlau machen.

Die etwas mehr abgehangene Alternative wäre Remoting. Ein komplettes 3-Tier-Architekturbeispiel mit mehreren Diensten, Sicherheit und einem Windows.Forms-Clients findest Du hier: .NET Applikationsserver

Remoting scheidet allerdings aus (bzw. sollte ausscheiden), wenn die Kommunikation übers Internet geht und Interoperabel sein muss. Zwar unterstützt Remoting auch SOAP, aber das ist eher halbgebacken. Da kommt immernoch zuviel .NET mit über die Leitung, als dass man die SOAP-Implementierung für Interoperable-Dienste verwenden könnte. Für reine .NET Anwendungen, die im LAN laufen, ist Remoting aber nach wie vor sehr gut geeignet. Einfach, schnell, sicher und skalierbar.

Ich hatte noch in keinem Projekt Probleme mit der Leistung oder der Zuverlässigkeit von Remoting. Auch wenn WCF featuremäßig und von der markstrategischen Positionierung des Herstellers überlegen ist, arbeite ich trotzdem viel lieber mit Remoting, als mit WCF.

Was das OR-Mapping angeht, wäre ich da in einer n-Tier-Anwendung sehr vorsichtig. Die Tatsache, dass das Changetracking der meisten OR-Mapper wirkungslos ist, sobald die Objekte auf den Client übertragen wurden, macht viel Arbeit, Blasen im Kopf und frisst u.U. sogar die Leistung auf. Näheres zu diesem Thema findest Du hier: http://yellow-rainbird.de/blogs/rainbird/archive/2009/01/09/habe-sehnsucht-nach-dem-rowstate.aspx

08.05.2009 - 00:00 Uhr

Kontextmenu des entsprechenden TableAdapters - konfigurieren - Enter, Enter, Enter.

Da kann ich nur voll zustimmen.

Der Designer ist seit Visual Studio 2005 ganz gut. Viele Leute sind noch aus Visual Studio 2002/2003 Zeiten negativ vorbelastet. Der Designer ist wirklich toll! Ich habe den Designer früher gehasst. Mittlerweile mache ich 95% mit dem Designer.

07.05.2009 - 23:52 Uhr

Remoting funktioniert folgendermaßen:

Wenn der Client einen entfernten Methodenaufruf startet, werden die Objekte, welche als Parameter übergeben werden, serialisiert. Beim IPC und TCP-Kanal wird dies standardmäßig mit dem System.Runtime.Serialization.Formatters.Binary.BinaryFormatter getan. Der BinaryFormatter benötigt das zu serialisierende Objekt und dessen Typeninformation, um das Objekt serialisieren zu können.
Sobald die Parameter serialisiert sind, werden sie als Datenstrom übers Netzwerk versendet.
Beim Server angekommen, muss Remoting ebenfalls wieder einen BinaryFormatter bemühen, um aus dem Datenstrom wieder die gewünschten Objekte zu bauen und diese in den Arbeitsspeicher zu laden. Dieser Vorgang nennt sich Deserialisieren. Damit der BinaryFormatter korrekt deserialisieren kann, benötigt er den Datenstrom und den Typ des Objekts, welches er aus dem Datenstrom bauen soll. Beim Rückgabewert geht es genau andersherum. Der Server serialisiert den Rückgabewert, schickt ihn zum Client und dieser deserialisiert ihn wieder in ein lokales Objekt.

Der BinaryFormatter kann nur Objekte serialisieren und deserialisieren, deren Klassen er kennt. Klassen sind immer in Assemblies definiert. Ohne die Assembly gibt´s gibts auch keine Typeninformationen. Deshalb müssen Server und Client beide alle Assemblies haben, deren Typen in einem entfernten Methodenaufruf verwendet werden.

Man kann deshalb sagen: "This behavior is by design!". Da gibt es nichts zu rütteln.

Die einzige Möglichkeit ist, keine eigenen Typen zu verwenden, sondern nur Typen als Parameter verwenden, die Bestandteil des .NET Frameworks sind. Da sowohl Server als auch Client die .NET Framewoks Assemblies haben, kennen auch beide all ihre Typen und können fröhlich serialisieren und deserialisieren.

Mit Objekten wie z.B. DataSet und DataTable kommt man da schon recht weit. So kannst auch auch sehr komplexe Datenstrukturen versenden.

Ganz ohne Kontrakt-Assembly kommst Du aber trotzdem nicht aus. Schließlich muss der Client die Schnittstelle des Remote-Objekts kennen, um überhaupt einen entfernten Methodenaufruf starten zu können. Um das zu vermeiden kann man die Implementierungs-Assembly auf den Client kopieren. Das ist aber nicht sinnvoll, da der Client die Geschäftslogik auch lokal aufrufen und den Server einfach umgehen kann. Alleine aus sicherheitstechnischen Gründen, ist davon abzuraten.

Die einfachste Möglichkeit, Remoting zu verwenden, findest Du hier: Remoting-Helfer

Aber ´ne Kontrakt-Assembly brauchst Du trotzdem. Sorry.

Anders sieht es allerdings bei ASP.NET-Webservices oder WCF auf. Da geht es ganz ohne gemeinsame Assembly. Stattdessen musst Du Dir aber clientseitig eine Proxy-Assembly generieren lassen, welche sich oft anders verhält, als das Originalobjekt. In reinen .NET Anwendungen macht diese Proxy-Assembly-Geschichte keinen Spaß. Wenn aber der Client z.B. eine Java-Anwendung ist, geht es natürlich nur so, da Java mit einer .NET Kontrakt-Assembly nicht anfangen kann. Wohl aber mit einem standadiersten WSDL-Kontrakt.

07.05.2009 - 02:37 Uhr

sprich ich will eigentlich nicht/ finde es unsinn in einer soa welt die daten die vorher selektiert wurden wieder an einen andren service zur weiterverarbeitung zu geben... sinnvoll wäre da doch sicherlich nur wenn dann die ids zu übergeben und der service müsste sich erneut die datensätze vom datenservice besorgen...

Dann wirst Du SOA generell nicht mögen.

Das ist nicht verwerflich, denn SOA ist nicht für alles und jeden geeignet. SOA verursacht einen sehr hohen Aufwand, viel Redundanz, jede Menge Infrastruktur und obendrauf sind SOA-Konstrukte definitiv recht träge.

SOA ist für Firmen geeignet, ...*... die komplexe Geschäftsprozesse haben *... deren Geschäftsprozesse sich oft ändern *... die sich das auch Leisten können und die nötige Infrastruktur haben

Und natürlich ist auch nicht jede Art von Anwendung für eine SOA geeignet.

Wenn man mit herkömmlichen Mitteln gut zurechtkommt, gibt es eigentlich keinen Grund, auf SOA umzusteigen. Es gibt ja auch keine einzige fertige Business-Anwendung, die wirklich nach SOA-Prinzipien funktioniert irgendwo zu kaufen.

In einer SOA-Umgebung müssen die Dienste autonom sein. Wenn alle auf die selbe Datenbank zugreifen und nur IDs austauschen, ist das nicht mehr der Fall. In einer echten SOA-Anwendung, müsste ich einen einzelnen Dienst einfach durch den eines anderen Herstellers austauschen können. Nur die Orchestrierungen und ggf. ein paar Mappings anpassen, und schon sollte es mit dem neuen Dienst laufen. Was das Produkt vom Hersteller X für eine Datenbank verwendet, oder ob überhaupt interessiert an dieser Stelle nicht.

Man muss, glaube ich, vom verbreiteten 3-Schichtendenken völlig weg, wenn man in Richtung SOA gehen will. Es steht da nicht mehr alles schön in Reih´und Glied im SQL Server, wo man es dann sofort mit SELECT x FROM y rausholen kann. Man muss Nachrichtenorientiert denken. Es werden nur och Nachrichten verschickt, empfangen, in Warteschlangen gestellt, transformiert und verarbeitet. Konsequenterweise, darf in einer SOA-Anwendung eine WCF-Operation NIEMALS direkt einen string oder einen DataContract zurückgeben. Alles muss mit MessageContracts gemacht werden. Nur so erhält man orchestrierbare und versionierbare Nachrichtentypen. Eine Dienstoperation kennt eine Anfragenachricht (request) und eine Antwortnachricht (response). Sonst nichts! Manchmal nicht einmal das, z.B. bei OneWay-Operationen. Damit wäre die Kommunikation zwar nachrichtenorientiert (also im Sinne von SOA), die eigentliche Implementierung der Geschäftslogik aber noch lange nicht.

Eine Möglichkeit in dieser Richtung weiterzukommen ist, die Anwendung in einer Infrastruktur aufzuhängen, die auch bei der Persistenz nachrichtenorientiert funktioniert. Z.B. ginge das mit dem BizTalk Server. Der hat eine sogenannte MessageBox, in der alle Nachrichten, die gerade irgendwo liegen, waren oder gerade eingegangen sind in einem großen Topf (unter der Haube ein SQL Server) abgelegt werden. Jede Nachricht hat ein Schema (XSD) und diverse Metadaten (welche auf dem Weg angesammelt wurden). Die Dienste von der Infrastruktur automatisch mit den Nachrichten versorgt, die für sie gedacht sind. Das ist aber eine ganz andere Art Software zu entwicklen, wie das die meisten von uns gewohnt sind.

Es ist aber am Ende nur Theorie. Solche Anwendungen existieren nicht (nur in einzelnen Teilbereichen wie z.B. EAI). Ob das wirklich so der Renner ist/wird, daran darf auch gezweifelt werden. Momentan ist der Aufwand zu hoch, um feingranulare Dienste (im Sinne von Bestandteile einer Anwendung) so autonom zu halten und über Orchestrierung zu verbinden.

Die meisten verstehen unter SOA, dass man die Geschäftslogik einer Anwendung über definierte Schnittstellen entfernt aufrufen kann. Man könnte diese Sichtweise auch vereinfacht so formulieren: SOA = (n-Tier + Webservices).

07.05.2009 - 01:51 Uhr

Hallo steven,

ein Typisiertes DataSet würde Dir da möglicherweise helfen, da der DataSet-Designer automatisch Methoden generiert, um sich von einer DataRow über die Relations zu deren Parent bzw. deren Childs durchzuhangeln. Das geht zwar untypisiert auch, aber nicht so schön. Außerdem haben Typisierte DataSets viele Vorteile beim Databinding.

07.05.2009 - 01:48 Uhr

Ersetze "(local)" im Connection String durch "localhost\SQLEXPRESS".

05.05.2009 - 22:56 Uhr

Anforderung der Kunden : Bei Erfassung der Rechnung muss die Nummer angezeigt werden, da sie manchmal aufgeschrieben wird um die Rechnung später nochmal aufzurufen. Es geht also nicht die Nummer später beim Speichern zu vergeben.

Die Rechnungsnummer ist kein künstlicher Schlüssel und sollte deshalb nicht als Primärschlüssel verwendet werde. Die Rechnungsnummer muss in Deutschland einen fortlaufenden Teil beinhalten. Viele Firmen verwenden zudem Rechnungsnummern, die auch Aussagen über die Rechnung machen (z.B. "W200911005615" um eine Werkstattrechnung vom November 2009 mit der Fortlaufenden Nummber 5615 darzustellen). Diese Nummer muss natürlich zentral von der Buchungslogik vergeben werden (Stichwort Key Provider). Im Falle eines Abbruchs oder eines nachträglichen Stornos muss die Rechnungsnummer dann eben in einem Storno-Log vermerkt werden (Sonst gibts Ärger mit dem Finanzamt). Die Rechnungserstellung beginnt in diesem Fall damit, dass der Client eine neue Rechnungsnummer anfordert, die er sofort bekommt, deren Vergabe mit Zusatzdaten (Zeitpunkt, Benutzer, Client) aber protokolliert wird. Wenn die fertig erfasste Rechnung später eingebucht wird, muss der Log-Eintrag gelöscht werden. Wird die Rechnungserfassung abgebrochen, verbleibt der Log-Eintrag der unzugewiesenen Rechnungsnummer in der Datenbank und kann als Nachweis verwendet werden, wo die Rechnungsnummer denn abgeblieben ist.

Eine Rechnungsnummer sollte deshalb kein Auto-Increment-Int-Wert sein. Wenn der Primärschlüssel des Rechnungsdatensatzes ein Guid ist, kann ich diesen Datensatz sofort überall nachverflgen, egal ob er noch im Hauptspeicher des Clients ist, in einer Message Queue festhängt, im Fehlertext einer Ausnahme im Applikationsserver auftaucht oder einwandfrei in der Datenbank eingebucht ist.

Deshalb: Gebt AutoIncrements keine Chance! 😉

Die Nummer muss ja auch wieder freigegeben werden wenn die Rechnungseingabe abgebrochen wird. Zurückgeben? Was ist wenn mehrere Benutzer gleichzeitig Rechnungen erfassen?

05.05.2009 - 22:34 Uhr

Hallo ErfinderDesRades,

die Sache ist nicht unproblematisch. Was passiert, wenn Du mit (verteilten) Transaktionen in einer Multi-User-Umgebung arbeitest?
Was machen offline Clients (z.B. die Anwendung auf dem Notebook des Außendienstlers)?

Das Problem ist dass, es bei numerischen Schlüsseln immer eine zentrale Instanz geben muss, die sich um die Vergabe der Schlüssel kümmert. Ob das nun ein Key Provider oder die Datenbank selbst ist, spielt da weniger eine Rolle.

Es gibt noch eine ganz andere Methode, nämlich die Schlüssel komplett dezentral zu vergeben. Damit das funktioniert, müssen auch ohne Zugriff auf die DB eindeutige Schlüssel erzeugt werden können. Dann spielt es keine Rolle, ob ein Schlüssel für einen Datensatz client- oder serverseitig erzeugt wird. Mit numerischen Schlüssel geht das allerdings nicht. Da müssen dann Guids her. Der SQL Sever unterstützt Guids mit dem Datentyp uniqueidentifier (Guids werden vom SQL Server intern nicht als Strings verarbeitet und auch nicht lahm, wie manche Leute glauben).

Wenn ich Guids als Primärschlüsselfelder verwende, kann ich auf dem Client offline einen neuen Schlüssel anlegen und dieser wird auch nach dem Persistieren der DataTable noch der Selbe sein.

offerRow.OfferId=Guid.NewGuid();

Ich kann aber auch genauso einen Schlüssel für die selbe Tabelle direkt in einem INSERT-Statement erzeugen:

INSERT Offer (OfferId,OfferDate,OfferNo,OfferUser)
VALUES (NEWID(),GETDATE(),@offerNo,@offerUser)

Ich kann so überall gültige Schlüssel erzeugen. Ich muss im Client nun keine Sonderbehandlung mehr für Datensätze machen, die noch nicht gespeichert wurden.

Der Einsatz von Guids als Schlüssel hat aber auch Nachteile:*Guids sind schwer zu merken und umständlich einzutippen *Guids sind keine fortlaufenden Nummern

Am Ende überwiegen aber die Vorteile. Ich finde es nicht schlimm, statt

SELECT * FROM Offer WHERE OfferID=456142

folgendes beim Testen einzutippen

SELECT * FROM Offer WHERE OfferID='38218659-6D03-48ac-B867-6C6A110E397F'

. Die Zwischenablage ist Dein Freund 😉.

Man sollte Guids allerdings nicht verwenden, wenn die Datenbank diese nicht als eigenen Datentyp unterstützt (z.B. MySql), da sie sonst als langsame Strings verarbeitet werden müssen.

04.05.2009 - 20:36 Uhr

Hallo Andreas@Tricept,

Microsoft verfolgt seit Office 2007 eine andere Strategie. Statt Office-Komponenten in andere Software zu bringen, soll die andere Software nun in Office integriert werden. Die Plug-In Entwicklung wurde mit VSTO stark vereinfacht und verbessert. Die Anbindung an eigene Anwendungen und deren Daten wird seit Office 2007 vorzugsweise mit Plug-Ins realisiert.

Als Alternative gibt es da z.B. RDL bzw. die SQL Reporting Services. Die ermöglichen schöne Diagramme und Berichte ganz ohne Office. RDL lässt sich direkt in eigene Anwendungen integrieren (Report Viewer-Steuerelement) und die Reporting Services von SQL Server 2000+ bringen ein Web-Portal fürs gesamte Berichtswesen gleich mit.

Excel bringt nur dann Vorteile, wenn der Benutzer mit den Daten "spielen" können muss.

30.04.2009 - 19:29 Uhr

Remoting muss nicht kompliziert sein.

Schau: Remoting-Helfer

29.04.2009 - 09:08 Uhr

Und wenn du nun sagst, dass es Leute gibt, die die mögliche Nicht-Existenz Gottes erschreckt, dann musst du auch zugestehen, dass es Leute geben kann, die die mögliche Existenz Gottes erschreckend. Gründe, warum für einen Nicht-Gläubigen die mögliche Existenz Gottes erschreckend wirken kann, habe ich ja oben schon genannt.

Das muss ich zugeben. Einem Nicht-Gläubigen könnte aus auch unwohl werden, wenn er sich plötzlich vorstellt, da ist ein unsichtbares Wesen, das in die ganze Zeit beobachtet und dessen Einfluss er sich - laut der Lehre - spätestens nach dem Tod nicht mehr entziehen kann. Er würde dann sozusagen daran zweifeln, dass es keinen Gott gibt.

Wie ich eingangs erwähnte: Ich bin hin- und hergerissen, ob ich die Kampagne zusammengefasst nun positiv oder negativ bewerten soll.

Im Prinzip macht die Kampagne die selbe Aussage wie Satan: "Menschen, ihr braucht keinen Gott, ihr kriegt das auch alleine hin.". Das soll jetzt nicht negativ sein, denn mir ist keine Stelle in der Bibel bekannt, wo Satan wirklich etwas böses gemacht hat (z.B. jemand gefoltert und dabei mit blitzenden roten Hörnern lauthals gelacht). Er hat nur immer die unangenehmen Fragen gestellt (Satan bedeutet soviel wie "Ankläger"). Gott wollte eigentlich keine Menschen, die selbst entscheiden, sondern treue Arbeiter mit kindlichem Gemüt. Jesus sagt deshalb: "Ihr müsst werden wie die Kinder". Die Gläubigen müsse sozusagen ihren symbolischen Anteil des Apfels vom Baum der Erkenntnis wieder zuzückgeben und dadurch zu dem werden, wass Gott eigentlich angestrebt hatte. Auch der Versuch Gottes ein auserwähltes Volk zu züchten, dessen Stammvater so loyal war, dass er ohne wirklichen Grund, seinen eigenen Sohn verbrannt hätte, hat nicht ganz hingehauen. Von daher spiegelt die Bus-Kampage eigentlich nur unser Wesen.

29.04.2009 - 08:20 Uhr

Vielleicht, weil es noch nie eine nichtreligiöse Aktion gab, die sich nicht GEGEN den Glauben, sonder FÜR ein Leben ohne Gott stark gemacht hat (das ist ein wichtiger Unterschied).

Ohne einen Gott funktioniert der Glaube nicht. Man kann statt Gott zwar etwas anderes an seine Stelle setzen (z.B. sagen manche Leute "Ich glaube an das Gute"), aber das hat nicht so eine gute Wirkung. In der Bibel steht "Woran Du Dein Herz hängst, das ist Dein Gott.". Der Glaube an einen Gott funktioniert deshalb so gut, weil sich die Gläubigen untereinander im Glauben bestärken. Dann kommen viel weniger Zweifel auf, als bei einem Glauben, denn sich ein einzelner für sich ausgedacht hat. Rituale (z.B. Abendnmahl, Taufe) und feierliche Orte (z.B. der Kölner Dom) sorgen für die nötige Atmosphäre, die viele der Gläubigen glauben lässt, manchmal die Anwesenheit Gotten wirklich zu fühlen. Die Illusion muss perfekt sein, sonst glaubt man nicht wirklich daran.

Nur, rainbird, ich verstehe es wirklich nicht - wie kann man als gläubiger Mensch Angst haben, dass es keinen Gott gibt? Ich meine, deshalb heisst es doch glauben. Da sollte kein Raum für Zweifel sein - auch so, wie ich die Bibel interpretiere, ist genau das der Punkt, der eingefordert wird - bedingungsloser, zweifelsfreier Glaube. Insofern sollte die Sorge, dass es vielleicht keinen Gott gibt, im Denken eines gläubigen Menschen doch überhaupt keinen Platz haben.

Im Idealfall (aus Sicht eines Gläubigen) sollte das so sein. Praktisch haben aber die meisten Gläubigen hin und wieder Zweifel. Wenn der Glaube nicht bedingungslos und zweifelsfrei ist, funktioniert er nicht. Die stärkende und befreiende Wirkung bleibt dann aus. Das ist unangenehm und wird definitiv wahrgenommen. Deshalb halten viele Gläubige eine Morgenandacht, besuchen Gottestdienste und halten Hauskreise ab usw. Der Glaube will gepfelgt werden, damit er sich nicht verflüchtigt.

Da aber religiöse Kampagnen zulässig sind, obwohl sie bestimmte Personengruppen erschrecken können, sollte auch eine atheistische Kampagne auf die Gefahr hin, bestimmte Personengruppen zu erschrecken, zulässig sein.

Alle religiösen Kampagnen, die ich in letzter Zeit gesehen habe, waren aber nicht erschreckend. Beispiele: "Gott! Mitten im Leben", "Pro Christ: Heute Zweifeln und Staunen!","Kath. Kirche: www.mach-dich-auf-und.com"
Das erschreckt niemanden. Wirklich nicht. Wenn Du aber eine Kampagne anderer Art gesehen hast, lasse ich mich gerne vom Gegenteil überzeuegen.

Gleichzeitig zeigt doch der erste Absatz, dass Gott keineswegs immer gut ist. Gott ist auch ein zorniger und strafender Gott (Sintflut, Sodom&Gomorra, Jüngstes Gericht usw.). Man kann eben nicht alles machen und Gott hat immer Verständnis dafür. Wenn wir Gottes Kinder sind, dann hat er ganz schön antiquierte und bisweilen auch unfaire Erziehungsmethoden.

Die Gläubigen habe selbst die Wahl, ob sie so leben möchten. Wenn sich Menschen an die Gebote ihres Gottes halten, diskriminiert das aber keine Atheisten. Wenn diese Menschen so glücklicher sind, warum nicht? Ein Satz über jahrtausende erprobter Leitlinien für das eigene Leben muss auch nicht schlecht sein. Manche Leute sind mit der großen Freiheit die bei uns momentan herrscht auch überfordert. Andere brauchen diese Freiheit um glücklich zu sein. Niemand wird doch dazu gezwungen.

28.04.2009 - 09:19 Uhr

Wenn ich über die Bus-Kampagne nachdenke. möchte ich gleichzeitig Hüh und Hott schreien.

Ich bin in einer sehr ländlichen Gegend aufgewachsen, wo Frömmigkeit noch eine Tugend ist. Atheisten werden manchmal diskriminiert und es wird seitens der Gläbigen versucht sie in eine bestimmte Richtung zu pushen. Von dieser Seite betrachtet finde ich die Kampagne super!

Auf der anderen Seite weiss ich aber auch, dass es sehr viele Menschen gibt, die ohne ihren Glauben verloren wären. Sie schöpfen aus ihrem Glauben ungeheuere Kraft. Für sie ist die Tatsache, dass es eine höhere Instanz gibt, die grundsätzlich gut ist und auf sie aufpasst, ungeheuer beruhigend. Sie können in bestimmten Situationen die Verantwortung an diese Instanz, diesen Gott, abtreten. Das befreit. Ob es diesen Gott, nun gibt oder nicht, spielt dabei keine Rolle. Der Glaube versetzt Berge. Das ist wie die Drachenrolle oder die geheime Zutat der Nudelsuppe im Film Kung fu Panda. Der feste Glaube daran entfacht die Wirkung, aber nicht der Gegenstand des Glaubens. Es ist quasi wie ein Plazebo.

Wenn diese Leute nun in die Stadt gehen und überall fahren Busse herum mit großen Bannern, auf denen steht "Es gibt keinen Gott!", dann macht das diesen Leuten Angst. Ich bin mir sicher, dass es manchen richtig flau im Magen wird. Nicht aus Zorn, oder weil das den Gott beleidigt, sondern weil in dem Moment die Angst da ist, der Satz könnte wirklich stimmen. An wen sollen diese Leute dann die Verantwortung für Dinge abtreten, die sie nicht beeinflussen können? Wie sollen sie sich noch sicher fühlen, wenn der Zweifel plötzlich da es, dass es keine beschützende unsichtbare Instanz gibt, die immer aufpasst? Nicht jeder ist so selbstbewusst, dass er das ertragen kann.

Die Angst, die sowas auslöst, ist nicht zu unterschätzen. Eine solche Kampagne sollte den Leuten aber keine Angst machen. Deshalb finde ich die gewählten Worte zu agressiv. Mir persönlich wären sie recht, aber wenn ich einen Schritt zurücktrete und das ganze Bild anschaue, dann überwiegen die negativen Auswirkungen dieser Kampagne.

27.04.2009 - 17:19 Uhr

...das würde das problem beheben, aber performant ist das ganze dann nicht mehr...

Warum?

Indizes beschleunigen für gewöhnlich den Zugriff, es sei denn die Daten werden öfter geändert, als gelesen (was in den meisten Fällen nicht zutrifft).

27.04.2009 - 14:25 Uhr

Du kannst Deinem C#-Projekt einen Verweis auf eine COM-Komponente zufügen. Um einen Verweis auf das Access-Objektmodell zuzufügen, gehst Du so vor:*Im Projekt-Explorer rechtsklick auf Verweise und dann "Verweis hinzufügen" wählen *Im Dialog zur Auswahl des Verweises auf die Registerkarte "COM" klicken *Aus der Liste den Verweis "Microsoft Access xx.x Object Library" auswählen (Wobei xx.x die Version ist! Access 2000 = Version 9.0, Access 2002 = Version 10.0, Access 2003 = Version 11.0, Access 2007 = Version 12.0) *Fertig!

Nun kannst Du von C# aus Access-Instanzen fernsteuern.

27.04.2009 - 06:51 Uhr

Hallo headbanger,

das wird so nicht funktionieren. SQL Server Compact Edition kann nicht direkt übers Netzwerk angesprochen werden. Es gibt aber trotzdem sehr einfachen Lösungen für Dein Problem:*1.Möglichkeit: Statt SQL CE könntest Du einen "richtigen" SQL Server (Express, Standard, ..) einsetzen (SQL Server Express ist kostenlos!). Den installierst Du dann auf dem Server-Computer, legst dort Deine Datenbank an und alle anderen Computer können dann per SQL auf die Daten übers Netzwerk zugreifen. *2. Möglichkeit: Du schreibst einen Windows-Dienst, der über WCF oder Remoting (Achtung! Das Compact Framework unterstützt kein Remoting!) übers Netzwerk ansprechpar ist. Dieser liest und schreibt aus bzw. in die lokale serverseitige SQL CE Datenbank. Die Clients müssen statt SQL einfach entfernte Methodenaufrufe auf dem Dienst ausführen. *3.Möglichkeit: Du verwendest einen "richtigen" SQL Server auf dem Server-Computer und auf jedem Client eine SQL CE Datenbank. Diese Konfigurierst Du für Replikation mit der "großen" Zentraldatenbank auf dem Server. Diesen Ansatz solltest Du allerdings nur wählen, wenn die Clients auch zeitweise ohne Server funktionieren müssen (z.B. Notebooks von Außendienstmitarbeitern).

Da es nur ein kleines Demo Projekt ist steht mir auch kein richtiger SQL Server zur Verfügung den ich "remote" ansprechen könnte.

Keine Hände, keine Kekse! SQL Server 2005/2008 Express Edition kannst Du hier kostenlos runterladen: http://www.microsoft.com/express/sql/ .
Es würden also keine Lizenzkosten entstehen. Du kannst den SQL Server Express auch direkt auf Deinem Entwickler-PC installieren. Ob der Server lokal oder entfernt angesprochen wird, spielt für Deine Anwendung keine Rolle. Die Vorgehensweise ist vollkommen identisch.

Mit SQL Server Express kannst Du bis zu 4 GB große Datenbanken verwalten. Das sollte für ein Demo-Projekt absolut ausreichend sein.

26.04.2009 - 15:34 Uhr

... da ich in das ganze drum herum um die Anwedung
nicht zu viel Zeit verschwenden möchte, wenn es so etwas
als leistungsstarkes Framework einzukaufen gibt ...

Diese Frameworks funktionieren für 0-8-15-Anwendungen gut. Wenn man aber mal ein Feature umsetzen muss, welches nicht von den Assistenten und vorgefertigten Tools eines solchen Frameworks abgedecket wird, dann hab man meistens Probleme. Vor allem zielen solche Frameworks meistens darauf ab, alles statisch zur Entwurfszeit festzulegen. Das ist für fast alle größeren Projekte aber kein gangbarer Weg. Da fehlt die Flexibilität. Zusammengeklickt sind solche Formulare wie im Demo-Video von StrataFrame sehr schnell, aber wehe, die Dinger sollen erweitert oder geändert werden.

Oder wie wird das von euch gehandhabt.
Programmiert ihr alles selber ???

Ja, definitiv! Allerdings hat Visual Studio bereits einige Designer die das Leben vereinfachen.

26.04.2009 - 15:14 Uhr

Hallo antoschka,

was meinst Du mit ASP? Active Server Pages oder Application Service Providing? Leider ist dieses Akronym nicht eindeutig. ASP.NET wäre eindeutig.

Was meinst Du mit Rich Client? Das kann alles mögliche sein: Silverlight? WPF? Windows.Forms?

Ich vermute mal, Du meinst Windows.Forms. Das MVC-Entwurfsmuster passt für Windows.Forms-Anwendungen nicht! Windows.Forms-Steuerelemente sind IMMER View und Controller im einem. Das ist nicht zu ändern. Deshalb ist grundsätzlich davon abzuraten, eine Windows.Forms-Anwendung so zu vergewaltigen, dass sie dem MVC-Muster genügt. Am Ende hat man dann nämlich jede Menge Abhängigkeiten, ein schier unkontrollierbares Event-Feuerwerk und die Garantie, dass sich kein anderer Kollege mehr an den Code traut. MVC ist für Windows.Forms deshalb ein Fall für den Papierkorb.

Was allerdings passt, wäre das Document-View Entwurfsmuster, wie es auch z.B. bei MFC-Anwendungen oft eingesetzt wurde.