Is that controllable?

What if I have complex object models referenced from wicket UI
components that I don't want (can't reasonably with Java's non optimal
serialization) serialized?

If we're serializing for offline storage aren't we going to require the
underlying model objects to get serialized as well?

> -----Original Message-----
> serialization in the context when you need to serialize the object -
> eg wicket serializes its pages for offline storage, etc.
> 
> -igor
> 
> On Thu, May 28, 2009 at 5:51 PM, Chris Colman
> <chr...@stepaheadsoftware.com> wrote:
> > Another extremely light weight IoC with ORM wrapping (JDO and
Hibernate)
> > is exPOJO at http://www.expojo.com
> >
> > No need for old fashioned DAOs etc., just POJOs being persisted
> > transparently the way they should be.
> >
> > In terms of serialization:
> >
> > Is that for the purpose of scaling in a cluster environment? I vote
for
> > 'session affinity' every time - it's almost necessary when you have
> > anything more sophisticated than an anemic domain model. Do you
really
> > want to be shifting complex object models from server to server via
> > serialization?
> >
> > If it's not for a cluster environment but for a single server to
allow
> > stale sessions to be swapped out then let the garbage collection
clean
> > out the ORM's object cache instead.
> >
> >> -----Original Message-----
> >> From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
> >> Sent: Friday, 29 May 2009 3:38 AM
> >> To: users@wicket.apache.org
> >> Subject: Re: Anemic domain model and are @SpringBean's compatible
with
> > the
> >> solution in "Spring 2.0 vs. the Anemic Domain Model"?
> >>
> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson
> > <kent.lars...@gmail.com>
> >> wrote:
> >> > Nice! I think Salve looks great! And it solves more than this
> > problem,
> >> > I like the design by contract module too as it allows me to
validate
> >> > parameters in a bit more declarative way.
> >> >
> >> > Do you think Salve is ready to be used in production? I'm a bit
> >> > concerned by "Although already usable, Salve is still in its
> > infancy.
> >> > Not all features have been implemented and not all problems
worked
> >> > out.". I only see one open issue and it doesn't seem too major
for
> > me
> >> > to pick it up.
> >>
> >> we have been using it in production for a while without any
problems.
> >> i just need to find the time to update the website text :)
> >>
> >> > If I'm not mistaken Salve may be used (for lots of things, but
one
> > is)
> >> > to solve serialization issues with Spring beans in Wicket
> > components?
> >> > But isn't that the same issue that the Wicket IOC and it's
> > @SpringBean
> >> > annotation solves?
> >>
> >> wicket ioc can only take it so far. because it has to generate a
proxy
> >> there are limitations to what classes can be proxies - eg no final
> >> methods, default constructor, etc. salve doesnt use a proxy so it
> >> doesnt have any problems.
> >>
> >> although small, wicket ioc does have an overhead of having to
> >> serialize the proxy with the componnet. since salve removes the
field
> >> it has no such overhead, this is more important when you are
returning
> >> large resultsets of entities that use dependencies.
> >>
> >> > If that's the case: Could I use Spring to inject my entities with
> >> > DAO's for now, and use the @SpringBean annotation on those as
well
> > in
> >> > my Wicket components (In those cases I have entities as class
vars)?
> >> > And the @SpringBean will solve the serialization issue?
> >>
> >> you can use whatever works for you. salve is an alternative :)
> >>
> >> > By just looking at Salve a bit it seems I could migrate to Salve
in
> >> > two steps that way. And it might be a pretty smooth path to take?
It
> >> > would mean that I inject 1000 entities for no good reason. But if
I
> >> > see a performance problem in doing so I could just migrate to
Salve?
> >> > By smooth path I mean that I would have access to my DAO's in my
> >> > entities and would essentially only change the dependency
> > annotations
> >> > and setup Salve.
> >>
> >> as long as you do not use spring-specific injection rules you
should
> >> be fine. salve uses lookup by type primarily, but also does have
> >> @SpringBeanId that can be used as a qualifier.
> >>
> >>
> >> > Of course, if Salve is production ready. Then could I throw out
> > Wicket
> >> > IOC and the @SpringBean annotation and use Salve instead to solve
> >> > serialization issues? In this case I would use Salve for my
> >> > presentation/Wicket -layer as well as dependency injection in my
> >> > entities and Spring as I already do for my service/business
-layer
> > and
> >> > my persistence/DTO -layer. Or would it be nicer to have Salve
handle
> >> > dependencies in the last two layers as well?
> >>
> >> we use salve to inject across all layers. it gives you a consistent
> >> approach to use and mock in unit tests. we have a spring context
that
> >> contains true services - eg session factory, mail sender, credit
card
> >> processor, etc. all of our domain model then uses salve to inject
> >> these wherever needed.
> >>
> >> -igor
> >>
> >> > A lot of questions and text. Thanks for reading this far! :-)
> >> >
> >> > Best regards, Kent
> >> >
> >> >
> >> >
> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
> > <igor.vaynb...@gmail.com>
> >> wrote:
> >> >> this is why i built salve.googlecode.com
> >> >>
> >> >> you can easily hook it into spring and have all your objects
(doman
> >> >> objects or wicket components) injected via @Dependency without
> >> >> worrying about serialization issues or eager injection - eg if
you
> >> >> load a result set of 1000 hibernate entities that need injection
> > you
> >> >> dont want all those injected for no reason.
> >> >>
> >> >> -igor
> >> >>
> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
> > <kent.lars...@gmail.com>
> >> wrote:
> >> >>> Hi,
> >> >>>
> >> >>> Our current architecture:
> >> >>> ---
> >> >>>
> >> >>> We're currently using a 3-tier architecture (presentation,
> >> >>> service/business and persistence) consisting of Wicket (+ a
little
> >> >>> Spring), Spring and Spring + Hibernate:
> >> >>>
> >> >>> Wicket:
> >> >>>
> >> >>> Does presentation, we're not inside a transaction / Hibernate
> > session
> >> >>> so all used fields must be loaded by Spring. We call Spring
> > singleton
> >> >>> beans and annotate those fields with @SpringBean.
> >> >>>
> >> >>> Spring:
> >> >>>
> >> >>> In the service layer we have Spring singleton beans, services,
> > which
> >> >>> are called from the Wicket layer. We have our transaction /
> > Hibernate
> >> >>> session boundary at this layer. We call DAO's from this layer.
> >> >>>
> >> >>> Spring + Hibernate:
> >> >>>
> >> >>> Our DAO's are Spring singleton beans which performs database
> >> >>> operations using HibernateTemplate.
> >> >>>
> >> >>> And common to all the layers are our entities. We use the
@Entity
> >> >>> annotation on them (not XML), from the Wicket layer we just use
> > the
> >> >>> accessor methods making sure that the relevant fields are
loaded
> > (as
> >> >>> we would get an exception if they were Lazy and not yet
loaded).
> > Our
> >> >>> entities are stupid, they lack logic and are used mostly like a
> > struct
> >> >>> in C/C++.
> >> >>>
> >> >>> I think the general pattern is pretty common for Java EE and
> > Spring
> >> >>> based web applications (feel free to disagree!). Yet it's
> > classified
> >> >>> as an anti-pattern by Martin Fowler as we are using mostly
> > procedural
> >> >>> programming and have an anemic domain model (
> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ).
> >> >>>
> >> >>> What I would like:
> >> >>> ---
> >> >>>
> >> >>> I would like to use a more OOP approach and have logic in our
> > current
> >> >>> entities, creating a rich domain model. For that to work in all
> > cases
> >> >>> they need to be able to load and save data. I would still use a
> > Spring
> >> >>> singleton bean's for different services. But instead of
changing
> > the
> >> >>> entities like structs they would be rich objects capable of
> > chaning
> >> >>> themself's and other objects.
> >> >>>
> >> >>> I found this article very interesting:
> >> >>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860
> >> >>>
> >> >>> But how would something like that work with Wicket? Could I
just
> > use
> >> >>> @SpringBean like I'm currently doing but use it on both
"entities"
> > and
> >> >>> Spring singleton services?
> >> >>>
> >> >>> For me this has a purely practical benefit, as I could use some
> >> >>> inheritance in the domain object model to create different
> > variations
> >> >>> of logic and not just data. Wicket feels quite agile and nice
to
> > work
> >> >>> with, but I still feel that the current architecture is a bit
> > stale
> >> >>> and seldom supports elegant OO solutions (that said, of course
> > things
> >> >>> can still be solved elegantly, I just think it would be easier
if
> > I
> >> >>> could do it in a more OO oriented way).
> >> >>>
> >> >>> Comments? What are the pros and cons of this kind of
architecture?
> >> >>>
> >> >>> All comments are greatly appreciated!
> >> >>>
> >> >>> Best regards, Kent
> >> >>>
> >> >>>
> >
---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >
---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >
---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> > For additional commands, e-mail: users-h...@wicket.apache.org
> >> >
> >> >
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG - www.avg.com
> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
> > 05/28/09
> >> 18:09:00
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date:
05/28/09
> 18:09:00

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to