Oops! Yes I'm talking about DAO's, not DTO's as I wrote. I guess I
shouldn't write acronyms after a long work day. ;-) Thanks for
spotting it!
Best regards, Kent
On Thu, May 28, 2009 at 6:07 PM, James Carman
<jcar...@carmanconsulting.com> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
