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
