[jdom-interest] EJB Mapper (was Newbie: JDom-Test)

[Alex Chaffee]

On Thu, Oct 05, 2000 at 06:26:16PM -0500, Brett McLaughlin wrote:
>
> Richard Landon wrote:
> > I've looked at the BeanMapper example in the jdom-contrib and want to
> > simulate something
> > akin to it for Entity EJB: we're using an MVC based EJB-centric design for
> > our system.
> > The idea being that we can return an XML document in a String as data when
> > we dispatch
> > the model change notification to the View (which exists within a JavaBean in
> > the Web-Tier).
> > I am dreaming, or just insane? I would appreciate any feed-back on the
> > general design
> > and approach (Really I would). I understand this is an XML not EJB forum,
> > but hey, it's
> > worth a shot? Here's a pointer to a discussion on XML and EJB that I'm
> > pretty much modeling
> > the approach after:
> > http://theserverside.com/patterns/thread.jsp?thread_id=343
> 
> This is a bad idea, frankly. I've been on Floyd to dump that one, but it
> is an open forum ;-) You don't want your EJBs returning XML; it exposes
> your business layer in a way that makes no sense in a Java application.
> Your servlet should talk RMI to th EJB layer - talking RMI to get back
> XML is a huge performance hit that gains you nothing in an all Java
> application. If your EJBs are returning XML to be used in presentation,
> then you have coupled your business layer to the presentation layer,
> which isn't good; if they are returning XML object graphs, then you are
> spending tons of time decoding XML into Java for no purpose.
> 
> I've seen lots of people doing this lately, and its just bad design.
> People are incredibly infatuated with XML, and using it way too much -
> use RMI for Java to Java, that's what it's there for. Then build
> presentation with your servlet. EJBs are business logic, not application
> or presentation logic.
> 

I agree that people are infatuated with XML, but there are a number of
reasons why it makes sense here.

The main one is the whole value object problem -- using RMI to walk
through each of the property getters and/or setters is abominably slow
-- this would allow you to ship all values to or from the client in a
single packet (or at least a single response stream).

Also, I disagree that it couples unduly -- it just adds a mapping
layer from the bean to an arbitrary XML representation.  You are free
to change the bean later and keep the same XML rep, which is, like,
the whole point of MVC.

Richard, I wrote BeanMapper recently, and it's still got some
holes/flaws, but in theory it should work fine on an EJB object, as
long as said object uses the JavaBean naming conventions for its
property accessors/mutators.  That is, if you have properties foo and
bar, just make 

	public Foo getFoo()
	public void setFoo(FooType foo)
	public Bar getBar()
	public void setBar(BarType bar)

and you should be able to call beanmapper.toDocument(this) from inside
a different method

	public String asXML() {
	  Document d = beanmapper.toDocument(this);
	  String s = xmloutputter.outputString(d);
	  return s;
   	}

Let me know how it works out!  And if you feel like adding support
for, e.g., List properties to BeanMapper while you're at it, that'd be
great too... :-)

 - Alex

-- 
Alex Chaffee                       mailto:alex at jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/