|
If I may, I would take it even to lower level. In
my personal experience often "the less is more". Less framework / managers is
more flexibilityand performance - as long as anarchy is not in the
picture.
There are very few reasons (other the lookup
information) for "persistance" in persistence solution as client is very much
stateful unlike HTML pages. Amount of direct manipultion of the data on server
level is greatly diminished. As complexity/amount of code on middleware level
decreases there is a huge advantage of making "thin server" solution.
Essentially the server becomes data access "driver"/ validation/transaction
facility.
I would say that XDoclet approach / annotations
seemed to work very well by allowing us to comfort Java users with flexibility
in code generator. It also allow for nice way to command which parts of
pojo code would be available to Flex.
In the end, you want to receive state information
from the client, that would drive all validation and transaction. You need just
to be able to generate DAO for retrieve / update directly from SQL that would be
compatible with those dataProviders. They become your basic stateful
dataProviders directly accessible from the client or as a part of a transaction.
In order to do transactions you need just another adapter/service point
that invokes validator and then in turn DAO objects using ThreadLocal
transaction.
I do not think there is much of a choice here
without huge duplication of persistence framework for transactional services to
support even 3 updates transactionally- especially if you are using
RemoteObject. Please see http://weblogs.macromedia.com/pent/archives/2005/02/operating_in_pa.cfm as
an example of the issues to submit transactions in small chunks ( please note
that due to "denial of service" restriction IE allows no more then 2 active
HTTPRequests, so WebServices or anything short of "remote scripting" gateway
would fail as well ).
And resources, concurrency and management of
server-based performance makes it applicable for a fraction of the
applications I was involved in.
I am sure someone will come with great idea of
using Struts/Hibernate to manage data requests - and it might even become
popular choice. I just do not think that one-size-fits-all solution really
exists. As a personal opinion I never seen anything "one-size-fits-all" that
actually fits.
Thank you,
Anatole Tartakovsky
----- Original Message -----
Sent: Monday, November 21, 2005 1:50
PM
Subject: [flexcoders] Re: Java Pojo to AS
pojo with ant
As you said, these are all opinions which are
always driven by our own
personal experiences. I do want to give a
bit of background on my
experiences, how they have effected my opinion, and
why I as well as
so many at Cynergy Systems are enamored with Flex, and why
we build
applications the way we do.
I have been developing Java
since Duke danced across my Mosaic Browser
while working as a Faculty
researcher at UMD (Go Terps!). I was a
Principal Architect at Sybase
for one of the first J2EE branded
application servers. I was involved
in the development not only of
J2EE applications, but the actual direction
of the specification
itself since version 0.4 way back in 1998. I am
a three time speaker
at JavaOne on subjects like "Advanced Transaction
Processing in J2EE"
(Google it, the presentation is still wandering the
net) as well as
CORBA, clustering etc. I also was a product manager
at that little
startup in Redmond WA.
I have plenty of
experiences to draw on to build my opinion. My
opinion is EJB was a
good try, a valiant attempt, and in the end an
over-architected
failure. I often say someday when I am rich and
famous and write my
memoirs I will apologize for ever driving EJB.
EJB is too heavy, too over
architected and designed for a software ISV
mentality that never fit the
intended market of business applications
developers. Fine, its
scalable, powerful, robust, open API's,
standards based, blah blah.
The root issue is that mere mortals
cannot be productive in it. Just
writing HelloWorld could take you
hours in EJB.
I know you
point out CMP (Container Managed Persistence for your
flexers) as being an
advantage of EJB. Actually if I could point to a
single monstrous
failure in EJB it was CMP. Its architecturally
flawed. The
finder() design is a memory hog, the ejb query syntax is
bizarre and
incredibly limiting, the whole assumption that the
database will not remain
consistent if you allow any other application
outside CMP to access it is
ridiculous (Google Distributed Diamonds),
etc. Trust me, if CMP were
so amazing why is it that EJB3's CMP model
is effectively just
Hibernate? And why do you have a quote from the
JBoss group?
Well maybe because Hibernate is *their* project.
EJB3's
implementation means they're invention is being pushed. Heck,
lets
look at JBoss for a moment. They realized EJB apps were so hard
to
build and maintain they built an entire company around
providing
consulting for their *free* server. That should shoot alarm
bells up
right away.
All you have to do is go to a former EJB Mecca
like TheServerSide (TSS
is kinda like the EJB version of FlexCoders) to see
that those guys
have changed lock stock and barrel to servlet based
solutions like
Spring, Hibernate, Tapestry, JSF etc. That place used
to be *the* EJB
discussion forum and those three letters are like rat
poison there.
To us at Cynergy Systems software is about people and
their user
experience. Its about getting software in peoples hands
quickly, for
a reasonable price and in as simple an environment as
possible. To me
EJB does none of that. Mixing a Flex UI with a
simple container, a
powerful persistence layer, state machine, etc is the
right solution.
I've been in the trenches with EJB, possibly more then
pretty much
most people, and I can tell you, I'm hard pressed to bring a
client
there again. I want to provide my clients with an
affordable,
scalable rich application they can maintain. To me that
is *not* EJB.
Just my $0.02. (Although I think its worth closer
to a buck twenty
five or so butÂ…)
--
Dave Wolf
Cynergy
Systems, Inc.
Macromedia Flex Alliance Partner
http://www.cynergysystems.com
Email:
[EMAIL PROTECTED]
Office: 866-CYNERGY
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
YAHOO! GROUPS LINKS
|
