Hallo! > > Deine Angaben unten helfen uns vor allem in den Unser-Interface > > Klassen, mich interessiert aber auch, was man (logisch und > > programmatisch) in den COM-Objekten beachten koennte/sollte. > > COM-Objekte laufen auch in .NET, allerdings sind Assemblies besser (Versionen, > kein Marshalling, ...). Wenn Ihr die COMs mit C++ entwickelt, braucht Ihr > nichts zu beachten, der Umstieg von VB auf VB.NET ist allerdings mit Aufwand > verbunden, da VB.NET deutlich leistungsf�higer ist. Nach meinen Erfahrungen > ist es sinnvoll, St�ck f�r St�ck neu zu schreiben, um auch die neuen > M�glichkeiten von VB.NET zu nutzen. > > ### hmmm, interessante Info, allerdings ist auch hier VB wieder > eine Konzernrichtlinie ... > ### es stellt sich nur die Frage, ob es nicht vielleicht sogar > sinnvoller ist, zuerst alles in ASP.NET zu entwickeln und dann > erst die ASP-Classic Version daraus zu machen, dann waere die > "Kompatibilitaet" fuer die Zukunft sicher gegeben, ist jedoch > auch irgendwie ein eigenartiger und vor allem wahrscheinlich > muehsamer Weg ...
Interessanter Ansatz - aber kann ein Server.CreateObject auch mit Assemblies einwandfrei umgehen? Zumindest �ber WebServices mit Schnittstellen in XML/UDDI d�rfte es funktionieren. > > Ich hab' zwar ausgetestet, dass ich eigentlich fuer die Ubergangsphase > > der Umstellung auf ASP.NET die COM-Objekte ganz gut auch in ASP.NET > > einbinden kann, dennoch macht mir dir moeglichst reibungslose > > Umstellung auf ASP.NET noch etwas Kopfzerbrechen ... > > Die Formulare sind m.E. das Hauptproblem bei der Umstellung. Zwar gibt es mit > WebForms tolle Objekte, mit denen man f�r das Web genau wie f�r Windows > programmieren kann, aber leider sieht das Endergebnis nur auf dem IE gut aus. > Mein Formulargenerator in ASP/VBS wird also nicht so schnell durch WebForms > verdr�ngt werden. Wichtig scheint mir also zu sein, grunds�tzlich Business-, > Pr�sentations- und Datenlogik von vornherein zu trennen. > > > ### das ist interessant, ich habe in den letzten Tagen nach ueber einem > Jahr wieder ASP.NET getestet und bin eigentlich gerade von den Formular- > Features nicht gerade ueberzeugt, vor allem wegen dem Handling und eben > der Cross-Browser Funktionalitaet - auch wir verwenden seit einiger Zeit > einige VB-Script-Klassen, mit denen wir die Formularfelder generieren ... Die WebForms sind schon gut (zumindest f�r das Intranet) und ich denke, dass der Markt hier sehr bald eine Auswahl an Webkomponenten bietet, die gut f�r beliebige Clients sind. Sehr brauchbar ist auf alle F�lle schon mal das Mobile Internet Toolkit. > ### Sind da Aenderungen in ASP.NET geplant, mit dem Verbesserungen kommen > werden, weisst Du da etwas?? Na, geplant ist eine Menge und den Rest wird der Markt liefern. Die klassischen Komponenten-Hersteller werden wohl zun�chst einmal die WindowsForms erweitern, also braucht's noch ein bisschen Geduld. Ich w�rde heute lediglich Intranet-Applikationen direkt in ASP.NET entwickeln und f�r das Internet zun�chst mit ASP arbeiten, aber nur wegen der vorhandenen Komponenten. Dabei nat�rlich die Datenlogik einschl. Logical-Record-Locking kapseln und die Businesslogik ebenfalls in eigene Komponenten packen. Die Pr�sentationslogik ist halt im Moment f�r mich in ASP effektiver zu entwickeln. Freundliche Gr��e Joachim van de Bruck | [aspgerman] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspgerman/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspgerman.asp
