java - Adding behaviour to DTO object -

this design question confuses me.

as know, object consist of attributes , behaviours. in web programming, have implemented several protocol objects dto. these like:

abstract abstractrequest{     public abstract abstractresponse apply(); ... }  mathlessonrequest extends abstractrequest{      public abstractresponse apply(){           ..do based on request     } ... }  historylessonrequest extends abstractrequest{     public abstractresponse apply(){           ..do based on request     } } 

and want , in controller want this:

@restcontroller class schoolrequestcontroller{      @requestmapping(value="/",method = requestmethod.post, produces = "application/json")     @responsestatus(httpstatus.ok)     @responsebody     public abstractresponse query(abstractrequest request){            return request.apply();     }  } 

so , can see, want give request classes responsibility execute asked for.

my question , design? right give dto objects responsibilities execute for? or dto objects data transfer?

ps:this design comes problem that, apply method needs outer references of other objects services, dao etc. elegant way inject dependencies instances?

usually dtos have no logic (or simple transformation logic, such returning person's age date of birth).

you can use pattern have there... definitely, it's objects not dtos more rich objects (that's good). you're not adding 'dto' suffix class names, you're doing fine, because request object have behaviour.

edit

i see you're trying do. it's possible using dependency injection + aop, think there other patterns might have more clear distinction , lot less black magic.

with approach want use, request entry point application (to core of domain) , represents use case want run.

the approach use, based on domain-driven design (ddd) , hexagonal architecture, have dtos might kind of binding transport technology (for example xml/json annotations). , use layer of application services serve façade domain logic. application service responsible orchestration, not business logic.

as part of orchestration, application service needs reference object have business logic. in ddd these objects aggregates.

i think write lot more this, there quite few resources explaining how design applications, , explanation there way better can here :).

if interested in this, , don't mind spending bit more time (and maybe few bucks). strongly suggest copy of growing object-oriented software , implementing domain-driven design. both excellent books, easy read, , luckily examples in java.