Are you talking about DAOs (data access objects) and not DTOs (data
transfer objects)? DTOs are typically not singletons. Nor are they
set up via spring.
On Thu, May 28, 2009 at 11:20 AM, Kent Larsson <kent.lars...@gmail.com> wrote:
> Do you have a separation between domain objects and DTO's? It sounds
> like you don't (and there is nothing wrong with that), but if you do,
> how do you inject the DTO into the entity? In my case each DTO is a
> Spring singleton bean.
>
> On Thu, May 28, 2009 at 4:17 PM, Will Jaynes <w...@jaynes.org> wrote:
>> I use the same setup as you, but I add the use of the
>> OpenEntityManagerInViewFilter. I still use only Spring services from within
>> Wicket (as much as possible), but the domain objects can be as full featured
>> as needed because a Hibernate session is always open when Wicket is using
>> the services.
>>
>> 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
