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
