Applicability of DAO
Hello everyone,
I'm working on a complaint registration application.
For getting Complaint we use WebServices provided by another application.
I think DAO can be a good solution but i'm not 100% sure there isn't others solution.
The WebService methods are related to the complaint lifecycle like :
- CreateComplaint
- ResolveComplaint
- CloseComplaint
....
Since there is no classic methods like "Load", "Save" and "remove", does the DAO fit this correctly with this or do you recommend me another solution ?
Regards,
Sebastien Degardin
[613 byte] By [
sdegardina] at [2007-11-27 1:34:14]
# 1
> Hello everyone,
>
> I'm working on a complaint registration application.
> For getting Complaint we use WebServices provided by
> another application.
>
> I think DAO can be a good solution but i'm not 100%
> sure there isn't others solution.
A solution for what? What are you saying in regards to using the Data Access Object design pattern, i.e. DAO?
Did you create/code/design the Web services?
When a Web service creates a complaint, does it store it somewhere? Where and how does the Web service store the complaint?
# 2
The WebSercvices Store the Complaint to a Database.The question was related to the kind of method we can find i a DAO.
# 3
> The WebSercvices Store the Complaint to a Database.How does the Web service store the Complaint in the database? > The question was related to the kind of method we can find i a DAO.In the sentence above ,what does "we can find i a DAO" mean?
# 4
from experience i find building a DAO layer for all data accesss is generally a good idea. In particular use the Abstract DAO factory pattern. and bundle the data in a ValueObject / Data Transfer object pattern.
what you are doing with this is eliminating coupling, removing dependancy and building a consitance data access API throughout your system. It is planning for the changes that everyone says will not happen but always do.
keep your DAO framework and your DTO framework each in there own jar. put the concrete instance each in there own jar.
if it comes time to spread the application over multiple servers. or changed the way you access the web service or other underlying data the application becomes very easy to maintain
if done right you need only add a jar in the class path and change a configuration file to specify what type of DAO you desire.
# 5
> Hello everyone,
>
> I'm working on a complaint registration application.
> For getting Complaint we use WebServices provided by
> another application.
>
> I think DAO can be a good solution but i'm not 100%
> sure there isn't others solution.
> The WebService methods are related to the complaint
> lifecycle like :
>
> - CreateComplaint
> - ResolveComplaint
> - CloseComplaint
> ....
>
> Since there is no classic methods like "Load", "Save"
> and "remove", does the DAO fit this correctly with
> this or do you recommend me another solution ?
You are mixing models.
Use cases involve things like "Create Compliant".
A data model involves things like "Insert Compliant Data".
The business layer translates the first into the second.
It very seldom is exclusively a one to one relationship.
# 6
> > Hello everyone,
> >
> > I'm working on a complaint registration
> application.
> > For getting Complaint we use WebServices provided
> by
> > another application.
> >
> > I think DAO can be a good solution but i'm not
> 100%
> > sure there isn't others solution.
> > The WebService methods are related to the
> complaint
> > lifecycle like :
> >
> > - CreateComplaint
> > - ResolveComplaint
> > - CloseComplaint
> > ....
> >
> > Since there is no classic methods like "Load",
> "Save"
> > and "remove", does the DAO fit this correctly with
> > this or do you recommend me another solution ?
>
> You are mixing models.
>
> Use cases involve things like "Create Compliant".
i know that, but the WebServices isn't under my control.
I have to use it with the given method.
>
> A data model involves things like "Insert Compliant
> Data".
know that, that's the reason i'm posting this.
Because, i agree that this webService include method which should be part of the application Logic and not the Integration Tier :D
>
> The business layer translates the first into the
> second.
>
> It very seldom is exclusively a one to one
> relationship.
But, as is, i think i shoud be anyway good to make a DAO for concern separation.
Don't you think so ?
Thanks for your response.
Regards,
Sebastien Degardin
# 7
> >
> > You are mixing models.
> >
> > Use cases involve things like "Create Compliant".
>
> i know that, but the WebServices isn't under my
> control.
> I have to use it with the given method.
>
You didn't understand what I was talking about.
The use case IS "Create Complaint". I didn't say you needed to change it. It doesn't need to change.
The used case is NOT the same as the data model.
> >
> > A data model involves things like "Insert Compliant
> > Data".
>
> know that, that's the reason i'm posting this.
> Because, i agree that this webService include method
> which should be part of the application Logic and not
> the Integration Tier :D
>
You statement above doesn't make that clear.
>
> >
> > The business layer translates the first into the
> > second.
> >
> > It very seldom is exclusively a one to one
> > relationship.
>
> But, as is, i think i shoud be anyway good to make a
> DAO for concern separation.
And I said exactly that.
You have code for the database layer.
You have code for the business layer.
The two are not the same.
The database layer has 'Insert' (and other) methods.
The business layer implements use cases by using the data layer.
One of the use cases that the business layer implements is "Create Complaint". How it does that is up to you but it is very likely that it is going to use the data model method that corresponds to "Insert Complaint". It can certainly use other data model methods as well.
