Ein mögliches Mißverständnis (zumindest hab ich hier das Gefühl bei Java immer) besteht imho darin, dass man meint zu stark von der Programmiersprache auszugehen.
Deshalb ist vielleicht ein Buch über .NET Anwendungsarchitektur (wie z.B. das Buch von Richter) besser um erst einmal einen Überblick zu bekommen.
Notes beherrscht man ja auch nicht, nur weil man zufällig LotusScript kann.
Und so ähnlich ist das bei J2EE, J2EE_on_spring oder was auch immer genauso.
Man muß sich einfach mit der Architektur beschäftigen, auf dem das ganze basiert.
Man kann sich z.B. eine bestehende ASP.NET Anwendung mit DAO-Anbindung nehmen und sich überlegen oder besser nachlesen, welchen Sinn die einzigen Komponenten haben.
In Notes ist das eigentlich nicht anders.
Die erfahrenen Leute haben hier einfach einen Überblick wie sie am effizientesten eine Notes Anwendung strukturieren. Nur haben da nicht so viele Leute drüber geschrieben wie z.B. in J2EE. Und es existiert keine formalisierte Sprache zur Beschreibung von Architektur.
Die Programmiersprache ist dabei nur ein kleiner Teil.
Wenn man natürlich z.B. den Sinn von Webservices in .NET versteht, kann man das auch in Notes verwenden.
In Notes ist diese Architektur evolutionär gewachsen. In J2EE und vermutlich .NET wird viel stärker versucht ständig neuere und bessere architekturelle Ideen zu pushen. Das liegt auf einer höheren Abstraktionsebene als "reine" Merkmale von Programmiersprachen wie z.B. Datenstrukturen, String-Handling, Algorythmen oder Encoding von Files.
Einfach weil sich beide Plattformen sehr gut für Erweiterungen eignen und weil sie eben die Hauptplattformen sind, an denen ständig gewerkelt wird. Das kann sehr anstrengend sein. Aber irgendwie auch effizient.
so ungefähr seh ich das jedenfall.
Z.T. kann das sich am Rande von Consulting bla-bla befinden (z.B. das grundsätzlich interessante Buch "Software Factories", das ich gerade lese). Meist aber eben nicht.
Nur braucht man eben auch Zeit. Man lernt effizientes Unit-Testing nicht in einem Monat. Irgendwie bringt es die hohe Abstraktionsebene mit sich, dass der Code eigentlich sehr wenig ist, man aber trotzdem leicht den Überblick verlieren kann, wenn man was falsch macht.
Axel
