Re: S2: Actions/DAO interaction getting messy...
Eric D Nielsen on 26/03/08 15:31, wrote: Adam Hardy on 26/03/08 00:28:43 Eric D Nielsen on 25/03/08 14:29, wrote: Its a Struts2/Spring2/JPA(Hibernate) based project. I'm using a slightly modified version of the Generic DAO pattern shown in the Java persistence with Hibernate book and/or the IBM ThoughtWorks very similar example. (Modified to allow Spring Based Injection of the JPA EntityManger, while falling back to a native Hibernate session inside the DAOs to allow a few more optimizations). So its basically Business Objects (POJOs) ---1:1--- DAOs which is a relatively normal pattern I beleive. Is it normal with that Generic DAO pattern to name the DAOs 'services'? In the Domain-Driven-Design paradigm that I generally follow, the services are objects which carry out operations that you don't want to specifically assign to one domain object. I'm willing to admit a LOT of confusion about DAOs v (Services | Managers) v business logic on POJOs. I will say that my Actions are taking things named services but typed as DAOs since I thought I would eventually migrate towards this extra tier, but have let to really understand what belongs there. I think a large part of my confusion comes from most examples I've seen where just about 100% of the method in the vast majority of service classes are proxied calls from the DAO. With only 1-2 methods added to a small percentage of the services. However we are getting quite far afield for Struts matters here. I'd be very happy to receive further enlightenment, but if its better to move this part of the discussion elswhere, please let me know... I guess you want the Spring design paradigm. It's relatively straight-forward although you're right - in alot of cases, the managers just wrap the dao calls with no added functionality. just use POJOs there. I believe this approach would work with the Model-Driven idea, but it feels a little odd to me to mark up the domain object with HTTP-specific details Yes it would do, but what do you mean by 'mark up the domain object with HTTP-specific details'? I don't think you have to touch the domain objects to code the re-construction of your incoming Bug POJO. Yay! Back to Struts matters... I haven't written any type converters yet, but from the examples I'd been seeing I thought you had to add a @TypeConversion annotation to accessors that wanted custom type conversion. http://struts.apache.org/2.x/docs/typeconversion-annotation.html So if I was using Model Driven, would this mean putting these annotation on the model. (much like the Vistor pattern for Validation) You don't have to use annotations if you don't want to. You can use property files instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2: Actions/DAO interaction getting messy...
Adam Hardy on 26/03/08 00:28:43 Eric D Nielsen on 25/03/08 14:29, wrote: Its a Struts2/Spring2/JPA(Hibernate) based project. I'm using a slightly modified version of the Generic DAO pattern shown in the Java persistence with Hibernate book and/or the IBM ThoughtWorks very similar example. (Modified to allow Spring Based Injection of the JPA EntityManger, while falling back to a native Hibernate session inside the DAOs to allow a few more optimizations). So its basically Business Objects (POJOs) ---1:1--- DAOs which is a relatively normal pattern I beleive. Is it normal with that Generic DAO pattern to name the DAOs 'services'? In the Domain-Driven-Design paradigm that I generally follow, the services are objects which carry out operations that you don't want to specifically assign to one domain object. I'm willing to admit a LOT of confusion about DAOs v (Services | Managers) v business logic on POJOs. I will say that my Actions are taking things named services but typed as DAOs since I thought I would eventually migrate towards this extra tier, but have let to really understand what belongs there. I think a large part of my confusion comes from most examples I've seen where just about 100% of the method in the vast majority of service classes are proxied calls from the DAO. With only 1-2 methods added to a small percentage of the services. However we are getting quite far afield for Struts matters here. I'd be very happy to receive further enlightenment, but if its better to move this part of the discussion elswhere, please let me know... just use POJOs there. I believe this approach would work with the Model-Driven idea, but it feels a little odd to me to mark up the domain object with HTTP-specific details Yes it would do, but what do you mean by 'mark up the domain object with HTTP-specific details'? I don't think you have to touch the domain objects to code the re-construction of your incoming Bug POJO. Yay! Back to Struts matters... I haven't written any type converters yet, but from the examples I'd been seeing I thought you had to add a @TypeConversion annotation to accessors that wanted custom type conversion. http://struts.apache.org/2.x/docs/typeconversion-annotation.html So if I was using Model Driven, would this mean putting these annotation on the model. (much like the Vistor pattern for Validation) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
S2: Actions/DAO interaction getting messy...
I'm starting to get some rather stinky code in one of my projects and wanted to
ask for some advice. (
Its a Struts2/Spring2/JPA(Hibernate) based project. I'm using a slightly
modified version of the Generic DAO pattern shown in the Java persistence with
Hibernate book and/or the IBM ThoughtWorks very similar example. (Modified to
allow Spring Based Injection of the JPA EntityManger, while falling back to a
native Hibernate session inside the DAOs to allow a few more optimizations).
So its basically
Business Objects (POJOs) ---1:1--- DAOs
which is a relatively normal pattern I beleive.
Now I'm working on an Action that creates an object that contains lots of
references to other objects. A bug tracker would be a reasonable facsimile of
my domain object -- when creating a bug, you select a severity, a project, a
module, a found in version, possibly you're assigning it to someone, etc. Most
of these options come from a drop-down on the view page, however they are all
backed by their own domain object -- ie its not just id/string display name
lookup-table backing the drop down.
So the form submits a whole suite of IDs or String natural keys and I need to
build an Defect/Bug and then persist it. In building the Defect I need to
convert all the keys to domain objects. This is where things begin to fall
apart. To covert the keys to domain object seems to require injecting all the
subordinate object DAOs into the Action, its not a big deal but its starting to
feel like the subordinate DAOs are taking over the action. Furthermore, its
slightly annoying from a performance stand-point that I need to retrieve all
the objects from the DB, just to set a foreign key -- I will never be updating
the details on the subordinate object from the master only changing which one
I'm linked to. [As a side issue: this is a place where the Get (returning a
proxy/lazy load thunk with only the ID set without hitting the DB) versus Load
could be useful, but I've never seen any of the generic DAO approaches expose
that level of control in their API -- does anyone know why?]
Here's an example (not from live code, please ignore any minor typos)
representing the current state of application and test code. Afterwards I'll
list a few of the approaches I've considered for cleaning it up:
AddBug.java
code:
public class AddBug extends ActionSupport {
private BugDAO bugService;
private UserDAO userService;
private ProjectDAO projectService;
private ModuleDAO moduleService;
private VersionDAO versionService;
private String submitterUsername;
private String assigneeUsername;
private Long projectID;
private Long moduleID;
private ListLong affectedVersionIDs;
public String execute() {
Bug bug = new Bug();
// The following lines are what feel unclean to me
bug.setSubmitter(userService.findByUsername(getSubmitterUsername()));
bug.setAssignee(userService.findByUsername(getAssigneeUsername()));
bug.setProject(projectService.find(getProjectID()));
bug.setModule(moduleService.find(getModuleID()));
for( Long versionID : getAffectedVersionIDs()) {
bug.addAffectedVersion(versionService.find(versionID));
}
bugDAO.persist(bug);
return SUCCESS;
}
// This block of setters also seems to be wrong... Only the first one
// should really be required by this action I think
public void setBugService(final BugDAO bs) {bugService=bs;}
public void setUserService(final UserDAO us) {userService=us;}
public void setProjectService(final ProjectDAO ps) {projectService=ps;}
public void setModuleService(final ModuleDAO ms) {moduleService=ms;}
public void setVersionService(final VersionDAO vs) {versionService=vs;}
public void setSubmitterUsername(final String username)
{submitterUsername=username;}
public void setAssigneeUsername(final String username)
{assigneeUsername=username;}
public void setProjectID(final Long id) {projectID=id;}
public void setModuleID(final Long id) {moduleID=id;}
public void setAffectedVersionIDs(final ListLong ids)
{affectedVersionIDs=ids;}
public String getSubmitterUsername() {return submitterUsername;}
public String getAssigneeUsername() {return assigneeUsername;}
public Long getProjectID() {return projectID;}
public Long getModuleID() {return moduleID;}
public ListLong getAffectedVersionIDs() {return affectedVersionIDs;}
}
TestAddBug.java
(Sorry this is purely from memory so I know I'm missing some of my
infrastructure)
code:
public void testAddBug() {
String submitterUsername=TestUser;
String assigneeUsername=TestVictim;
User submitter=new User(submitterUsername);
User assignee=new User(assigneeUsername);
UserDAO userService = createMock(UserDAO.class);
Re: S2: Actions/DAO interaction getting messy...
Eric D Nielsen wrote:
I'm starting to get some rather stinky code in one of my projects and wanted to
ask for some advice. (
Its a Struts2/Spring2/JPA(Hibernate) based project. I'm using a slightly
modified version of the Generic DAO pattern shown in the Java persistence with
Hibernate book and/or the IBM ThoughtWorks very similar example. (Modified to
allow Spring Based Injection of the JPA EntityManger, while falling back to a
native Hibernate session inside the DAOs to allow a few more optimizations).
So its basically
Business Objects (POJOs) ---1:1--- DAOs
which is a relatively normal pattern I beleive.
Now I'm working on an Action that creates an object that contains lots of
references to other objects. A bug tracker would be a reasonable facsimile of
my domain object -- when creating a bug, you select a severity, a project, a
module, a found in version, possibly you're assigning it to someone, etc. Most
of these options come from a drop-down on the view page, however they are all
backed by their own domain object -- ie its not just id/string display name
lookup-table backing the drop down.
So the form submits a whole suite of IDs or String natural keys and I need to
build an Defect/Bug and then persist it. In building the Defect I need to
convert all the keys to domain objects. This is where things begin to fall
apart. To covert the keys to domain object seems to require injecting all the
subordinate object DAOs into the Action, its not a big deal but its starting to
feel like the subordinate DAOs are taking over the action. Furthermore, its
slightly annoying from a performance stand-point that I need to retrieve all
the objects from the DB, just to set a foreign key -- I will never be updating
the details on the subordinate object from the master only changing which one
I'm linked to. [As a side issue: this is a place where the Get (returning a
proxy/lazy load thunk with only the ID set without hitting the DB) versus Load
could be useful, but I've never seen any of the generic DAO approaches expose
that level of control in their API -- does anyone know why?]
Here's an example (not from live code, please ignore any minor typos)
representing the current state of application and test code. Afterwards I'll
list a few of the approaches I've considered for cleaning it up:
AddBug.java
code:
public class AddBug extends ActionSupport {
private BugDAO bugService;
private UserDAO userService;
private ProjectDAO projectService;
private ModuleDAO moduleService;
private VersionDAO versionService;
private String submitterUsername;
private String assigneeUsername;
private Long projectID;
private Long moduleID;
private ListLong affectedVersionIDs;
public String execute() {
Bug bug = new Bug();
// The following lines are what feel unclean to me
bug.setSubmitter(userService.findByUsername(getSubmitterUsername()));
bug.setAssignee(userService.findByUsername(getAssigneeUsername()));
bug.setProject(projectService.find(getProjectID()));
bug.setModule(moduleService.find(getModuleID()));
for( Long versionID : getAffectedVersionIDs()) {
bug.addAffectedVersion(versionService.find(versionID));
}
bugDAO.persist(bug);
return SUCCESS;
}
// This block of setters also seems to be wrong... Only the first one
// should really be required by this action I think
public void setBugService(final BugDAO bs) {bugService=bs;}
public void setUserService(final UserDAO us) {userService=us;}
public void setProjectService(final ProjectDAO ps) {projectService=ps;}
public void setModuleService(final ModuleDAO ms) {moduleService=ms;}
public void setVersionService(final VersionDAO vs) {versionService=vs;}
public void setSubmitterUsername(final String username)
{submitterUsername=username;}
public void setAssigneeUsername(final String username)
{assigneeUsername=username;}
public void setProjectID(final Long id) {projectID=id;}
public void setModuleID(final Long id) {moduleID=id;}
public void setAffectedVersionIDs(final ListLong ids)
{affectedVersionIDs=ids;}
public String getSubmitterUsername() {return submitterUsername;}
public String getAssigneeUsername() {return assigneeUsername;}
public Long getProjectID() {return projectID;}
public Long getModuleID() {return moduleID;}
public ListLong getAffectedVersionIDs() {return affectedVersionIDs;}
}
TestAddBug.java
(Sorry this is purely from memory so I know I'm missing some of my
infrastructure)
code:
public void testAddBug() {
String submitterUsername=TestUser;
String assigneeUsername=TestVictim;
User submitter=new User(submitterUsername);
User assignee=new User(assigneeUsername);
UserDAO userService = createMock(UserDAO.class);
Re: S2: Actions/DAO interaction getting messy...
Eric D Nielsen on 25/03/08 14:29, wrote: Its a Struts2/Spring2/JPA(Hibernate) based project. I'm using a slightly modified version of the Generic DAO pattern shown in the Java persistence with Hibernate book and/or the IBM ThoughtWorks very similar example. (Modified to allow Spring Based Injection of the JPA EntityManger, while falling back to a native Hibernate session inside the DAOs to allow a few more optimizations). So its basically Business Objects (POJOs) ---1:1--- DAOs which is a relatively normal pattern I beleive. Is it normal with that Generic DAO pattern to name the DAOs 'services'? In the Domain-Driven-Design paradigm that I generally follow, the services are objects which carry out operations that you don't want to specifically assign to one domain object. [As a side issue: this is a place where the Get (returning a proxy/lazy load thunk with only the ID set without hitting the DB) versus Load could be useful, but I've never seen any of the generic DAO approaches expose that level of control in their API -- does anyone know why?] that's a pure Hibernate thing, I think, not a JPA distinction. just use POJOs there. I believe this approach would work with the Model-Driven idea, but it feels a little odd to me to mark up the domain object with HTTP-specific details Yes it would do, but what do you mean by 'mark up the domain object with HTTP-specific details'? I don't think you have to touch the domain objects to code the re-construction of your incoming Bug POJO. Regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] S2: Actions/DAO interaction getting messy...
The other benefit of the DAO / Manager / Action layers is that you can use spring to wire up the Manager/Service methods as the transaction boundaries. Sets of changes you want to all succeed or fail atomically? Put it in the manager. Managers are where business logic belongs, DAO's where DB maintenance logic belongs, Actions are just one interface into this, as you can expose managers as web services, too... -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
