3 Schicht Architektur

[Guest]

Ich schreibe oft 2 Schicht Swing Anwendungen:

(Client)
View
Controller
Modell
DAOs (Hibernate)
--------
(Server)
Datenbank

Man ließt und hört ja immer viel von 3 Schicht Architekturen, das möcht ich jetzt gerne mal ausprobieren.
Hab schon einiges über EJB gelesen, hab da aber noch ein paar Fragen:

Ist das ein zukunftsträchtiger Weg? Oder ist Spring eine bessere Alternative?

Wobei ich den Zusammenhang nicht ganz verstehe, wie hilft mir Depency Injection dabei entfernte Objekte zu benutzen? Wie findet mein Client diese Objekte und was sind das dann konkret für Objekte am Server? (Servlets oder J2SE Anwendung mit RMI...?!?! was ist das?)

Wenn ich jetzt ein paar Services am Server habe, wie gehe ich dann vom Ablauf vor? Habe ich am Client und am Server ein Model? View ändert Daten diese werden übertragen und gespeichert... oder werden nur die Aktionen vom Kunden an den Server übertragen und der Ändert dort das Model, speichert und zurück... oder wie kann ich mir so einen Ablauf vorstellen?

Das ist alles noch sehr abstract und auch die meisten Beschreibungen sind im Netz sind alle sehr abstract, kann mir jemand eine HandsOn Tutorial oder eine Beispielimplementierung nennen?



Danke für die Tips ;-)

 

[empi]

Gratuliere, Deine 2-Schichten-Architektur ist in Wirklichkeit eine 3 Schichten Architektur

1: Design (View)
2: Logik (Controller)
3a: Datenverwaltung (Hibernate)
3b: Datenhaltung (Datenbank)

 

[SlaterB]

Controller sind normalerweise keine eigene Schicht einer 3 Schichten Architektur, sondern Teil des Views,
siehe auch
http://www.java-forum.org/de/viewtopic.php?t=71886

aber eh alles Interpretationssache

 

[empi]

vielleicht hilft Dir das hier auch weiter:
http://www.developer.com/java/ejb/article.php/10931_3650661_1
http://www.laliluna.de/ejb-3-tutorial-jboss.html

 

[byte]

Wobei ich den Zusammenhang nicht ganz verstehe, wie hilft mir Depency Injection dabei entfernte Objekte zu benutzen? Wie findet mein Client diese Objekte und was sind das dann konkret für Objekte am Server? (Servlets oder J2SE Anwendung mit RMI...?!?! was ist das?)

Dependency Injection hat erstmal nichts mit verteilten Objekten zu tun. Da Du bei DI aber keine Objekte explizit mit new erzeugst, ist DI aber eine sehr guter Mechanismus zum Erzeugen von Proxies, wie man sie z.b. für Remote Procedure Calls einsetzt.
Konkret: Wenn Du Spring einsetzt, ist das Erzeugen von Remote Objekten sehr einfach. Du definierst einfach ein Interface, dass Client und Server kennen. Die konkrete Implementierung liegt auf dem Server. Mit Hilfe von DI kannst Du nun dieses Objekt den Clients verfügbar machen. Das funktioniert nicht programmatisch sondern über die Konfiguration. Welches Protokoll Du benutzt, bleibt Dir überlassen. Du kannst es so konfigurieren, dass RMI eingesetzt wird oder das Ganze über einen Servlet-Container laufen lassen.
Auf dem Client wird dann mit Hilfe von DI ein Proxy erzeugt, der vom Typ Deines Interfaces ist. Programmatisch merkst Du von der Verteiltheit also nicht viel. Du programmierst sowohl auf dem Server als auch auf dem Client nach dem von Dir definierten Interface.

Wenn ich jetzt ein paar Services am Server habe, wie gehe ich dann vom Ablauf vor? Habe ich am Client und am Server ein Model? View ändert Daten diese werden übertragen und gespeichert... oder werden nur die Aktionen vom Kunden an den Server übertragen und der Ändert dort das Model, speichert und zurück... oder wie kann ich mir so einen Ablauf vorstellen?

Es gibt verschiedene Vorgehensweisen. Wenn Du Domain Driven Design einsetzt, dann definierst Du ein Domain-Modell, dass sowohl vom Server als auch vom Client genutzt wird. Du reichst direkt die Domänenobjekte zw. Client und Server hin und her.
Eine andere Vorgehensweise sieht den Einsatz von DTOs vor. Das heisst, die Domänenobjekte werden nicht direkt vom Server zum Client gegeben, sondern zunächst in Data Transfer Objects verpackt.
Welches Konzept das richtige ist, muss jeder für sich entscheiden. Beides hat gewisse Konsequenzen. Persönlich halte ich das DDD-Konzept für besser. Man muss sich aber über die Konsequenzen bewusst sein, die es mitsich bringt, (persistente) Entitäten zum Client weiterzureichen.

 

[maki]

Gratuliere, Deine 2-Schichten-Architektur ist in Wirklichkeit eine 3 Schichten Architektur

1: Design (View)
2: Logik (Controller)
3a: Datenverwaltung (Hibernate)
3b: Datenhaltung (Datenbank)

Herzlichen Glückwunsch, alle 3 Schicht Architekturen sind in wirklichkeit 4 Schicht Architekturen

 

[byte]

Gegen Entrichtung eines kleinen Obulus schreibe ich Euch eine Anwendung mit 7 Schichten.

 

[FArt]

@byto

Immer zwei mal mehr als du...


Ach ja, und nimm nicht eine Architektur weil es cool ist. Fange an mit POJOs und Spring. Wenn ein MBean Server sinnvoll ist, hilft dir Spring. Wenn ein Applicationserver nötig ist ebenfalls.. Webserver... was auch immer du willst, es sind nur noch Architekturen und Container um deine Logik. Bei gutem Design mit nicht allzuviel Aufwand austauschbar.

 

[ps]

aber noch ein paar Fragen:

Ist das ein zukunftsträchtiger Weg? Oder ist Spring eine bessere Alternative?

JavaEE ist definitiv ein zukunftsträchtiger Weg. Hier im Forum sind allerdings ein paar glühende Spring Verfechter (Hallo byto ). Du wirst hier also zwei Meinungen hören und beide haben ihre Berechtigung. JavaEE ist ein definierter Standard - und mit JavaEE 5 sind die Gründe welche damals zur Entstehung von Spring geführt haben meiner Meinung nach weitgehend relativiert worden.
Dazu muss man verstehen das Spring als Alternative zu JavaEE 4 entstanden ist welches die Komplexität verteilter Systeme noch nicht so gut vor dem Entwickler versteckt hat. Dies führte zu sehr viel Konfiguration... ein weiteres Problem war das EJB2 sehr intrusiv war - es gab keine POJOs.
Mit JavaEE 5 wurden diese Schwächen beseitigt. Persönlich finde ich es jetzt sehr viel einfacher als Spring, wobei dieses ja aus vielen fragmentierten Einzelteilen besteht - und man schon genauer definieren müsste was man genau meint.. da du aber den Vergleich mit JavaEE ziehst gehe ich jetzt mal von einem relativ kompletten Stack aus (spring di, spring remoting, spring acegi, etc).

Persönlich mache ich meine Anwendung lieber von JavaEE abhängig als von Spring - das ist aber wohl Geschmackssache.

vielleicht ganz interessant: http://java.dzone.com/videos/interview-adam-bien-defends-ja

Wenn ich jetzt ein paar Services am Server habe, wie gehe ich dann vom Ablauf vor? Habe ich am Client und am Server ein Model? View ändert Daten diese werden übertragen und gespeichert... oder werden nur die Aktionen vom Kunden an den Server übertragen und der Ändert dort das Model, speichert und zurück... oder wie kann ich mir so einen Ablauf vorstellen?

Die Domain Objekte zwischen den Tiers zu transportieren hat wie byto bereits erwähnt hat Vor- und Nachteile. In großen verteilten Systemen ist eine klare Trennung der Schichten aber IMHO nach wie vor anzuraten. Man erkauft sich sonst eine schnellere Entwicklung mit komplexerer Wartung / Erweiterung. Auch das hängt aber natürlich sehr stark von der Anwendung ab die entwickelt wird. Oft hat man ja auch verschiedene Sichten auf die Daten, je nachdem welcher Client connected oder welcher Benutzer eingeloggt ist - zB. in einem mandantenfähigen System. Dann bleibt einem fast nur die DTO Variante.

 

[tfa]

Also ich kann nur zu Spring raten. Gerade wenn man sich in der Vergangenheit eher mit 2-Schicht-Anwendungen befasst hat, also bisher auf Application-Server verzichten durfte. Bei Spring sind die nämlich nicht notwendig. Gerade bei kleineren Anwendungen ist dies zusammen mit dem modularen Aufbau von Spring meiner Meinung nach ein Vorteil. Ohne Server-Infrastruktur kann dies kann auch zu einer besseren Unit-Testbarkeit führen, in EJB-Umgebungen sind wohl eher aufwendigere Integrationstest notwendig.
Nichtsdestotrotz sind selbstverständlich auch große Systeme mit Applicationserver genauso einfach möglich wie mit EJB.

Das Argument, dass EJB ein Standard sei und Spring nicht, halte ich für ziemlich uninteressant. Wenn du dich nach Standard richten willst, dürftes du Java gar nicht anfassen, sondern müsstest alles mit C++ oder C# machen. Man muss sich für das Produkt entscheiden, was zur Problemlösung am besten geeignet ist. Das kann EJB sein und das kann auch Spring sein.
Außerdem erscheint mir die Community für Spring größer zu sein als EJB 3.0. Schau dir z.B. mal das offizielle Spring-Forum und das offizielle EJB-Foum an und entscheide, was dir besser gefällt.
Zum Einsatz von Spring bzw. EJB hat byto hat in diesem Thread mal ein paar nette Charts gepostet (die dann auch kontrovers diskutiert wurden :wink: ).

 

[byte]

Hier noch ein paar interessante Links zum Thema Spring vs EJB:

- Spring is the new Java EE
- IBM Websphere zertifiziert Spring
- BEA Weblogic und Spring Kooperation
- Oracle und Spring

 

[ps]

Ja, Spring wird langsam (sehr langsam) auch durch die bekannteren im Appserver Markt unterstützt. (BEA Weblogic gibts übrigens nicht mehr ^^)
Und hallo: Das große Argument für Spring ist doch eigentlich das es so leichtgewichtig ist und man keinen Appserver braucht. Und jetzt kommen Links von Appservern die Spring unterstützen... ich bin verwirrt ;-)

Auch ganz interessant:
-> http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

 

[tfa]

Auch ganz interessant:
-> http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

Ja, vor ca. 3 Jahren war der Artikel sicher ganz interessant. Aber mittlerweile sind einige Aussagen doch ziemlich veraltet.

 

[ps]

Auch ganz interessant:
-> http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

Ja, vor ca. 3 Jahren war der Artikel sicher ganz interessant. Aber mittlerweile sind einige Aussagen doch ziemlich veraltet.

Welche?

 

[FArt]

Und hallo: Das große Argument für Spring ist doch eigentlich das es so leichtgewichtig ist und man keinen Appserver braucht.

Oft brauch man keinen Applicationserver, manchmal doch.. manchmal tut es auch ein Tomcat, oder ein MBean-Server... zumindest bin ich mit Spring nicht auf die Containerarchitektur fesgelegt und kann ohne viel Aufwand eine Portierung vornehmen.

 

[tfa]

Zum Beispiel:

Spring's programming interface is primarily based upon XML configuration files

Das allermeiste lässt sich mittlerweile annotieren.

EJB 3.0 configures declarative services using Java annotations, while Spring uses XML configuration files. In most cases, the EJB 3.0 annotation approach is the simpler and more elegant way for this type of services.

Siehe oben.

In Spring, it is more difficult to optimize the interaction between the framework and the services. For instance, in order to use Spring's declarative transaction service to manage Hibernate transactions, you have to explicitly configure the Spring TransactionManager and Hibernate SessionFactory objects in the XML configuration file.

Einen TransactionManager musste ich noch nie explizit konfigurieren. Das geht alles per Annotationen.

 

[ps]

Und hallo: Das große Argument für Spring ist doch eigentlich das es so leichtgewichtig ist und man keinen Appserver braucht.

Oft brauch man keinen Applicationserver, manchmal doch.. manchmal tut es auch ein Tomcat, oder ein MBean-Server... zumindest bin ich mit Spring nicht auf die Containerarchitektur fesgelegt und kann ohne viel Aufwand eine Portierung vornehmen.

Sowohl Spring als auch EJB3 arbeiten mit POJOs. Du legst dich bei Spring sehr wohl auch auf einen Container fest: Auf den Spring DI Container. Bei Spring jedoch hast du dazu genau eine Implementierung zur Wahl, bei EJB3 einige mehr. Wenn du schonmal versucht hast eine Spring Anwendung von dem ach so "nicht invasiven" Spring Bibliotheken zu befreien weisst du auch was ich meine.

Spring hat DI groß gemacht, warum die Leute das vorher nicht eingesetzt haben.... keine Ahnung. So ist das eben mit Hypes ^^ Die Möglichkeit dazu besteht in JavaSE jedenfalls seit Ewigkeiten. Komplett ohne Container. Ich sehe aber mittlerweile viele Anwendungen welche DI einsetzen, einfach weil es "The Spring Way" ist. Zu viel DI schadet aber nur anstatt das es hilft.

 

[tfa]

doppelt

 

[ps]

Zum Beispiel:

Spring's programming interface is primarily based upon XML configuration files

Das allermeiste lässt sich mittlerweile annotieren.

Ok.

Einen TransactionManager musste ich noch nie explizit konfigurieren. Das geht alles per Annotationen.

Eine Annotation ist bei dir keine Konfiguration?

 

[tfa]

Eine Annotation ist bei dir keine Konfiguration?

Ich hab es zu sehr verkürzt: in order to use Spring's declarative transaction service to manage Hibernate transactions, you have to explicitly configure the Spring TransactionManager and Hibernate SessionFactory objects in the XML configuration file.
Diese @-Konfiguration hast du bei EJB ja auch.
In sofern: siehe oben. Aber ich glaube, der halbe Artikel dreht sich um XML vs. Annotationen. :wink:

 

[ps]

Diese @-Konfiguration hast du bei EJB ja auch.
In sofern: siehe oben. Aber ich glaube, der halbe Artikel dreht sich um XML vs. Annotationen. :wink:

Mhm nein, du hast keine @-Konfiguratoin in EJB:

@PersistenceContext
EntityManager em;

Das reicht völlig - vorausgesetzt es gibt nur eine PersistenceUnit (persistence.xml). Aber TransactionManager, SessionFactory... damit komme ich idR. nicht in Berührung. Nicht in einem EJB.

 

[tfa]

Soetwas mein ich ja mit @-"Konfiguration". Du musst ja irgendwo dranschreiben (also konfigurieren), dass z.B. bestimmte Service-Methoden einen Transaktionskontext benötigen. Und das geht eben durch Annotationen.

 

[ps]

Soetwas mein ich ja mit @-"Konfiguration". Du musst ja irgendwo dranschreiben (also konfigurieren), dass z.B. bestimmte Service-Methoden einen Transaktionskontext benötigen. Und das geht eben durch Annotationen.

Das oben ist alles - diese Annotation injiziert mir den EntityManager. Es ging in dem von dir gequoteten ja um einen "TransactionManager" und eine "SessionFactory". Beide brauche ich nicht.

Jede Methode im EJB bekommt automatisch einen Transaktionskontext. Convention over Configuration Man kann es explizit konfigurieren, muss es aber nicht wenn einem die Vorgabe zusagt. Man benötigt auch keine manuelle Transaktionssteuerung (begin,commit, rollback) - das verschlankt den code ungemein

Aber wir werden leicht OT ^^

 

[ARadauer]

Aber wir werden leicht OT ^^

das macht nix, solche diskussionen schaden nie

 

[tfa]

[Jede Methode im EJB bekommt automatisch einen Transaktionskontext. Convention over Configuration Man kann es explizit konfigurieren, muss es aber nicht wenn einem die Vorgabe zusagt. Man benötigt auch keine manuelle Transaktionssteuerung (begin,commit, rollback) - das verschlankt den code ungemein

Ist in Spring nicht anders. Ich schreibe nur an die Klasse (oder das Interface), deren Methoden in Transaktionen ausgeführt werden sollen, @Transactional. Wenn nötig, kann ich da noch Parameter angeben oder in jeder beliebigen Methode überschreiben. In der Konfiguration muss ich nur angeben, dass ein TransactionManager verwendet wird und von welchem Typ er ist (z.B. ein Standard-TM, der auf die verwendete Persistenzschicht zugeschnitten ist, oder ein PM, der globale und nichtlokale Transaktionen beherrscht.) Diese eine Zeile XML kann man grad noch tolerieren.

 

[byte]

Du legst dich bei Spring sehr wohl auch auf einen Container fest: Auf den Spring DI Container.

Nur dass bei Spring der "Container" ein Jar ist und bei EJB ein Server.

Wenn du schonmal versucht hast eine Spring Anwendung von dem ach so "nicht invasiven" Spring Bibliotheken zu befreien weisst du auch was ich meine.

Tu doch nicht so, als hättest Du auf einmal fundierte Spring Kenntnisse. Das glaubt Dir hier eh keiner mehr.
Abgesehen von einigen Helper-Klassen findest Du nichts vom Spring-Framework in Deinen POJOs. Davon abgesehen wüsste ich nicht, warum man eine Anwendung von Spring "befreien" sollte. ???:L Die Lib ist Open Source und unter der Apache Lizenz 2.0 veröffentlicht.
Es ist seit jeher eine stärke von Java, dass es für viele Standardaufgaben sehr gute Libraries gibt, die man frei nutzen kann. Und das soll bei Spring jetzt auf einmal schlecht sein, nur weil es keinen JSR dazu gibt? Ist doch lächerlich.

Zu viel DI schadet aber nur anstatt das es hilft.

Begründest Du Deine eigene Meinung auch noch oder lässt Du das so frei im Raum schweben?

Und hallo: Das große Argument für Spring ist doch eigentlich das es so leichtgewichtig ist und man keinen Appserver braucht. Und jetzt kommen Links von Appservern die Spring unterstützen... ich bin verwirrt ;-)

Nur weil Spring Dich nicht dazu zwingt, einen EJB-Container einzusetzen, heisst das nicht, dass Du nicht die Möglichkeit hättest, einen Servlet-Container einzusetzen. Viele Unternehmen haben (historisch gewachsen) kommerzielle Application-Server lizensiert. Diese kann man natürlich auch einsetzen, für gewisse Dinge auch unabdingbar (z.B. verteilte Transaktionen).
Naja, aber dass Du offenbar leicht verwirrt bist, merke ich schon länger. :roll: Anders lässt sich Dein Anti-Spring Feldzug leider nicht erklären.

 

[ps]

Nur dass bei Spring der "Container" ein Jar ist und bei EJB ein Server.

OMG. Was ist das denn für Schwachsinn? Auch ein Server kommt als JAR daher.

Tu doch nicht so, als hättest Du auf einmal fundierte Spring Kenntnisse. Das glaubt Dir hier eh keiner mehr.
Abgesehen von einigen Helper-Klassen findest Du nichts vom Spring-Framework in Deinen POJOs.

Das habe ich auch nicht behauptet. Ich habe keine fundierten Kenntnisse. Die POJOs sind schon größtenteils frei von Spring (wie sie im übrigen bei EJB auch frei von EJB sind... das zeichnet beide Technologien aus). Das größere Problem ist das ohne spring.xml halt nichts mehr so tut wie es soll. Wenn dann noch die tollen Spring Abstraktionen für die Persistenz benutzt werden ist es ganz vorbei mit dem Spaß.

Davon abgesehen wüsste ich nicht, warum man eine Anwendung von Spring "befreien" sollte. ???:L

Zugegeben, die Anwendung war ziemlich übel - eben eine von diesen die im Spring Hype entstanden sind und an jeder Ecke DI einsetzen mussten, ohne sich Gedanken darüber zu machen an welcher Stelle das sinnvoll gewesen wäre und an welcher es einfach nur Hirntot ist. Das machte sie schwer zu warten. Da gab es so tolle Sachen wie Spring Annotations oder eine IDE mit Spring Refactoring leider noch nicht.

DI ist kein Selbstzweck - und wenn man nicht verstanden hat an welcher Stelle DI in einer Architektur Sinn macht - dann verschlimmbessert ein DI Framework wie Spring nur alles. Die Leute denken sich dann nicht mehr so viele Gedanken darüber machen zu müssen, "The Spring Way" sagt ihnen ja wies geht: hauptsache DI.

Zugegeben, dieses Problem gibts bei EJB auch.

Die Lib ist Open Source und unter der Apache Lizenz 2.0 veröffentlicht. Es ist seit jeher eine stärke von Java, dass es für viele Standardaufgaben sehr gute Libraries gibt, die man frei nutzen kann. Und das soll bei Spring jetzt auf einmal schlecht sein, nur weil es keinen JSR dazu gibt? Ist doch lächerlich.

Die Entwicklung von Spring ist aber alles andere als frei. Die Lizenz alleine machts halt nicht.

Zu viel DI schadet aber nur anstatt das es hilft.

Begründest Du Deine eigene Meinung auch noch oder lässt Du das so frei im Raum schweben?[/quote]

Mein Gesunder Menschenverstand. Wenn ich an jeder Ecke eine lose Kopplung habe, auch dort wo sich die Implementation nie ändern wird dann geht das auf Kosten der Stabilität. Ich bekomme Alpträume wenn ich mir vorstelle meine Anwendung nur von einer windigen XML Datei zusammenzuhalten.

-> http://www.infoq.com/news/2007/12/does-di-pay-off
DI ist super - in Maßen. Und wenn man weiß was man da tut und wesshalb. Hier gehts darum ob Testbarkeit alleine ein ausreichendes Argument ist..

> http://martinfowler.com/articles/injection.html
Dependency Injection is a useful alternative to Service Locator. When building application classes the two are roughly equivalent, but I think Service Locator has a slight edge due to its more straightforward behavior. However if you are building classes to used in multiple applications then Dependency Injection is a better choice.

Naja, aber dass Du offenbar leicht verwirrt bist, merke ich schon länger. :roll: Anders lässt sich Dein Anti-Spring Feldzug leider nicht erklären.

Danke - ich mag deine Argumentationen auch

 

[maki]

OMG. Was ist das denn für Schwachsinn? Auch ein Server kommt als JAR daher.

Ach ja, welcher denn?
Von der Installation und Ressourcenanforderung ganz zu schweigen.
Selbst JBoss braucht schon einiges...

 

[byte]

Nur dass bei Spring der "Container" ein Jar ist und bei EJB ein Server.

OMG. Was ist das denn für Schwachsinn? Auch ein Server kommt als JAR daher.

Siehst Du den unterschied zw. Jar in Classpath einbinden und eine Anwendung auf einen EJB-Container (aka AS) deployen?

Das größere Problem ist das ohne spring.xml halt nichts mehr so tut wie es soll. Wenn dann noch die tollen Spring Abstraktionen für die Persistenz benutzt werden ist es ganz vorbei mit dem Spaß.

Was genau meinst Du? Ja, die Spring-Konfiguration via XML ist notwendig. Wo genau ist das ein Problem? Und was soll der letzte Satz sagen? Du sprichst in Rätseln.

Zugegeben, die Anwendung war ziemlich übel - eben eine von diesen die im Spring Hype entstanden sind und an jeder Ecke DI einsetzen mussten, ohne sich Gedanken darüber zu machen an welcher Stelle das sinnvoll gewesen wäre und an welcher es einfach nur Hirntot ist. Das machte sie schwer zu warten. Da gab es so tolle Sachen wie Spring Annotations oder eine IDE mit Spring Refactoring leider noch nicht.

Es trifft auf jede Technologie zu, dass man damit auch Blödsinn anstellen kann, wenn man keine Ahnung hat, was man tut.

DI ist kein Selbstzweck - und wenn man nicht verstanden hat an welcher Stelle DI in einer Architektur Sinn macht - dann verschlimmbessert ein DI Framework wie Spring nur alles. Die Leute denken sich dann nicht mehr so viele Gedanken darüber machen zu müssen, "The Spring Way" sagt ihnen ja wies geht: hauptsache DI.

siehe oben

Zugegeben, dieses Problem gibts bei EJB auch.

Und auf alle anderen DI-Libs auch. Der Entwickler muss schon wissen, was er tut.

Die Entwicklung von Spring ist aber alles andere als frei. Die Lizenz alleine machts halt nicht.

Die Apache Lizenz 2.0 ist eine der Lizenzen mit den größten Freiheiten. Es steht Dir frei, die Lib zu forken und selbst weiterzuentwicklen. Der einzige Unterschied ist, dass es keinen JSR zu Spring gibt. Das trifft aber auf fast alle Third-Party-Libraries zu. Oder nutzt Du etwa keine davon?

Wenn ich an jeder Ecke eine lose Kopplung habe, auch dort wo sich die Implementation nie ändern wird dann geht das auf Kosten der Stabilität.

Wie sieht denn die Alternative ohne DI in der Praxis häufig aus? Durch übermäßigen Einsatz von Singletons entsteht ein Wirrwarr an fest verdrahteten Implementierungen. Diese nachträglich aufzulösen ist grausam. Da ist mir eine XML-Datei deutlich lieber, wo ich die Verdrahtungen der Objekte sehen und steuern kann.
Im übrigen ist Spring-DI längst annotiert, so dass die XML-Konfigurationen wesentlich schlanker geworden sind.

 

[ps]

OMG. Was ist das denn für Schwachsinn? Auch ein Server kommt als JAR daher.

Ach ja, welcher denn?

Sowohl Glassfish, OpenEJB als auch JBoss sind mittlerweile "embeddable".

Von der Installation und Ressourcenanforderung ganz zu schweigen.
Selbst JBoss braucht schon einiges...

JBoss ist ja auch ein Monster Insgesamt muss ich dir aber widersprechen - moderne Applicationserver laden dynamisch das nach was benötigt wird. Der Overhead ist also verschwindend gering. Glassfish v3 startet fast sogar schneller als Tomcat =)

 

[maki]

Sorry, aber einen AS mit Spring zu vergleichen ist voll daneben, 512MB ram in der Standardkonfig vom JBoss ist nicht dasselbe wie Spring.

Testen auf einem AS mutiert immer ganz schnell zum Integrationstest, von wegen TDD bzw. "schnelle" Tests.

Abgesehen davon hat die EJB Spek vieles aus Spring übernommen, nur leider kommen EJB Speks viel zu langsam raus, ganz zu schweigen von den Implementierungen der Speks, mit einem AS hinkt m,an der Entwicklung zwangsläufig immer hinterher.

Klar kann man auch Vorteile haben wenn man einen AS benutzt, aber wenn man keinen braucht (Globale Transaktionen), ist man ohne besser dran.

 

[ps]

Siehst Du den unterschied zw. Jar in Classpath einbinden und eine Anwendung auf einen EJB-Container (aka AS) deployen?

Sagt dir embedded Mode etwas?
-> http://www.theserverside.com/news/thread.tss?thread_id=49227

GlassFish glassfish = new GlassFish();
// create smallest possible HTTP set up listening on port 8080
glassfish.minimallyConfigure(8080);

GFApplication app = glassfish.deploy(new File("path/to/simple.war"));
...
app.undeploy();
glassfish.stop();

Wow - ein ganzer Application Server in einer JAR. Wie geht das denn jetzt?

Es trifft auf jede Technologie zu, dass man damit auch Blödsinn anstellen kann, wenn man keine Ahnung hat, was man tut.

Meine Meinung ist halt das Spring diesen Blödsinn unterstützt.

Die Apache Lizenz 2.0 ist eine der Lizenzen mit den größten Freiheiten. Es steht Dir frei, die Lib zu forken und selbst weiterzuentwicklen. Der einzige Unterschied ist, dass es keinen JSR zu Spring gibt. Das trifft aber auf fast alle Third-Party-Libraries zu. Oder nutzt Du etwa keine davon?

Es geht nicht um die Lizenz - es geht ums Entwicklungsmodell. Ein Fork bringt mir überhaupt nichts - der Aufwand die Bibliothek selbst zu warten ist für die meisten Firmen zu hoch. Gibt es also Möglichkeiten für die Community die Richtung von Spring mitzubestimmen? Prioritäten zu setzen? Eben genau das wofür der JCP eingerichtet wurde?
Oderhat Interface21 da seine Hand drauf... ?

Wie sieht denn die Alternative ohne DI in der Praxis häufig aus? Durch übermäßigen Einsatz von Singletons entsteht ein Wirrwarr an fest verdrahteten Implementierungen. Diese nachträglich aufzulösen ist grausam. Da ist mir eine XML-Datei deutlich lieber, wo ich die Verdrahtungen der Objekte sehen und steuern kann.

Das ist wohl eine Geschmacksfrage - mir ist sogar eine Factory um einiges lieber als eine XML Datei. In der Regel benutze ich aber die DI Funktionalitäten von JavaSE (und die Lookup API).

 

[maki]

Wow - ein ganzer Application Server in einer JAR. Wie geht das denn jetzt?

Wow, ein ganzer AS für eine Webapp... *g*

Sorry, aber mit einer EAR sieht die Sache wieder komplexer aus, bezweifle dass das einfacher ist als Spring, ich weiss das die Ressourcenanforderungen ganz anders sind.

Wozu einen AS?

Was kann man damit machen, was ohne nicht geht?
Mir fällt nix anderes als implizite globale Transaktionen ein, wie oft braucht man die?

 

[ps]

Sorry, aber einen AS mit Spring zu vergleichen ist voll daneben, 512MB ram in der Standardkonfig vom JBoss ist nicht dasselbe wie Spring.

Keine Ahnung wieviel der JBoss frisst, das war aber schon immer ein Speicherkiller. Und der Vergleich ist sehr wohl berechtigt - es kommt halt drauf an was du für deine Anwendung benötigst. Wir reden hier aber von 3-Schicht-Architekturen und hier kommst du mit dem DI Container alleine nicht mehr aus.

Nochmal: Auch ein moderner Appserver ladet dynamisch nur genau die Funktionalitäten welche deine Anwendung benötigt.

Testen auf einem AS mutiert immer ganz schnell zum Integrationstest, von wegen TDD bzw. "schnelle" Tests.

Äh ja? Dann machst du irgendwas falsch. Ich kann meine EJB Anwendung genaus ausserhalb des Containers testen wie eine Spring Anwendung.
Stichwort: ejb3Unit: http://ejb3unit.sourceforge.net/

Abgesehen davon hat die EJB Spek vieles aus Spring übernommen, nur leider kommen EJB Speks viel zu langsam raus, ganz zu schweigen von den Implementierungen der Speks, mit einem AS hinkt m,an der Entwicklung zwangsläufig immer hinterher.

Was ist das denn jetzt für ein lahmes Argument? Klar ist EJB3 eine Reaktion auf Spring. Na und? Was interessiert mich das denn wenn ich eine technologie auswähle um eine Aufgabe zu erledigen?
Das man mit einem AS hinterherhinkt.. wenn du meinst. Ich wüsste jetzt nicht in welchem Punkt.

Klar kann man auch Vorteile haben wenn man einen AS benutzt, aber wenn man keinen braucht (Globale Transaktionen), ist man ohne besser dran.

Ich weiß nicht ob man ohne besser dran ist - einen Server brauchst du fast immer. Ob jetzt Tomcat oder ein anderer Servlet behälter.. Und wie gesagt, es tut sich viel auf dieser Front:
-> http://java.dzone.com/articles/glassfish-and-tomcat-whats-the
-> http://raibledesigns.com/rd/entry/glassfish_2_vs_tomcat_6

Das altbackene Argument der überfrachteten Applicationserver ist einfach nicht mehr länger gültig. Man kann sich jetzt weiterhin in der Vergangenheit verkriechen oder sich für neue Möglichkeiten öffnen. Wie man es eben für richtig hält.

 

[ps]

Wow, ein ganzer AS für eine Webapp... *g*

Ja - meine Webapps laden in GFv3 schneller als in jedem Tomcat. Sogar zum entwickeln sehr praktisch

Sorry, aber mit einer EAR sieht die Sache wieder komplexer aus, bezweifle dass das einfacher ist als Spring, ich weiss das die Ressourcenanforderungen ganz anders sind.

Nein, das sieht nicht viel anders aus. Die Ressourcenanforderungen sind vergleichbar wenn man zwei Anwendungen hat welche die selben Funktionalitäten haben.

Wozu einen AS?

Was kann man damit machen, was ohne nicht geht?
Mir fällt nix anderes als implizite globale Transaktionen ein, wie oft braucht man die?

Es geht immer alles auch ohne irgendwas. Die Frage ist wie komfortabel man ans Ziel kommt.
-> http://java.dzone.com/videos/interview-adam-bien-defends-ja

 

[byte]

Was hat man denn davon, einen AS einzubetten, ausser dass Resourcen flöten gehen?

 

[ps]

Was hat man denn davon, einen AS einzubetten, ausser dass Resourcen flöten gehen?

Provokativ: Was hat man denn davon, Spring einzubetten, ausser dass Resourcen flöten gehen?

Es ging mir eigentlich nur darum das fadenscheiniges Argument mit der JAR zu entkräften. Ob Spring oder AS, beides kann als JAR daherkommen. Das ist noch lange kein Argument für "leichtgewichtigkeit".

Weder Spring noch EJB sind leichtgewichtig wenn man ein gewisses Grad an Funktionalität benötigt. Und ob ich mir jetzt die JARs manuell zusammenklaube oder ob mir der AS nur die Teile lädt welche ich brauche. Von den Resourcenanforderungen ändern sich nicht viel.

Im Prinzip sind sich die beiden Welten ähnlicher als man denkt - beide wollen die selben Aufgaben lösen. Und beide machen das mehr oder weniger gut. Ich glaube sogar das es hier kein "besser" gibt. Und ich glaube jeder von uns hat mittlerweile klar gemacht warum ihm das eine oder andere besser zusagt.

 

[byte]

Was hat man denn davon, einen AS einzubetten, ausser dass Resourcen flöten gehen?

Provokativ: Was hat man denn davon, Spring einzubetten, ausser dass Resourcen flöten gehen?

Jetzt wirds aber arg lächerlich.

 

[ps]

Was hat man denn davon, einen AS einzubetten, ausser dass Resourcen flöten gehen?

Provokativ: Was hat man denn davon, Spring einzubetten, ausser dass Resourcen flöten gehen?

Jetzt wirds aber arg lächerlich.

Mit Argumenten hast dus wohl nicht so heute? Deine Frage ist genauso lächerlich und bescheuert wie meine Gegenfrage. Was hat man von einem AS? Was hast du von Spring? x_X
Lassen wir das, du scheint ziemlich lernresistent zu sein. Ich bin raus aus dem thread.

 

[byte]

Ich habe nicht gefragt, was man von einem AS hat, sondern was man von einem eingebetteten AS hat.