I'd suggest that we opened the door to using persisted objects
directly when we added Model-Driven and ParameterFilter to the
standard release. Even if we had a unamious agreement to remove
Model-Driven support across the board, we'd have to go through a long
deprecate/remove cycle. In the meantime, I'd like to continue the push
to support configuration by annotation.
-Ted.
On 10/25/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
>
> Martin Gilday wrote:
> > I would agree with that slightly. However with Struts 2 it is often
> > conveinient to have fields which are simply your Hibernate domain
> > models, especially if you are following paramsPrepareParams. You might
> > have a form allowing them to change their name but not their signup
> > date.
> >
> I can understand the issue with Hibernate domain objects that provide
> setters, but in most cases I control the values the user shouldn't be
> setting using Hibernate listeners or in my service tier. I usually only
> consume data in the web tier that I know the user has access to.
>
> > My main concern was users setting dao/services to null or another value,
> > as the setters for those are required by the Spring plugin. Is this a
> > valid concern, is is possible to alter these?
> >
> I usually avoid having services with setters in the action class. In
> fact, I usually inject everything via the constructor (I use Guice for
> this) to protect my action even more. When I absolutely have to have a
> setter for something and I want to protect it, I move it back to a
> different tier that Struts doesn't control. i.e.
>
> public class MyAction {
> private MyService service;
>
> @Inject
> public MyAction(MyService service) {
> this.service = service;
> }
> ...
> }
>
> and sometimes:
>
> public class MyServiceImpl implements MyService {
>
> @Inject
> public MyServiceImpl(SomeSessionObject object) {
> ...
> }
> ...
> }
>
> The MyService interface belongs to an intermediate tier between the
> business/data services and the web tier. I call it the web-service tier,
> but people get confused with traditional SOAP/XML WebServices. It
> essentially has access to web assets like the session and requests and
> such, but isn't controlled by the web frameworks and is just a simple
> POJO service.
>
> -bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
