Ah, I just saw Autowired and the fact that you answered within three minutes. I thought I wasn't clear enough, but apparently I was. I have to say I'm *very* impressed! :-)
I'll check this out more and I'll post my results here later on (after that I'll go into your other tip [in the other mail list thread]). Your Wicket Advanced example has been very educational (for me) to look at, I highly recommend it to others! If this works out I may be getting close to my dream development environment. :-) Until later! Best regards Kent On Thu, May 28, 2009 at 4:22 PM, James Carman <jcar...@carmanconsulting.com> wrote: > No, I mean @Configurable/@Autowired > > http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Configurable.html > > http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Autowired.html > > > With these, you can also use AspectJ to set things up. There are > aspects in spring-aspects.jar that takes care of it. You have to > introduce the AspectJ compiler into your build, but I believe that's > done for you in my wicket-advanced example application. > > On Thu, May 28, 2009 at 9:49 AM, Kent Larsson <kent.lars...@gmail.com> wrote: >> You mean @SpringConfigured("something") like in the linked article? >> >> On Thu, May 28, 2009 at 3:41 PM, James Carman >> <jcar...@carmanconsulting.com> wrote: >>> In your entities, you don't use @SpringBean. You use >>> @Configurable/@Autowire. >>> >>> On Thu, May 28, 2009 at 9: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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
