Design question for DAO interface

[lasse_stromberg]

Hi@all,

i'm designing some Service and DAO interfaces for my application at the moment and i'm not sure if it is better to include full domain objects in the signatures or only the identifiers (in my case a long type).

For example:

variant a):

public void changeRequestStatus(Request request, Status status);

variant b):

public void changeRequestStatus(long requestId, Status status);

Status is an enumeration and Request my domain object.

What is considered the better design?
Thx in advance!
-lasse

[tatvamasi]

Assuming both variants are thought for DAO and not for "Service" also assuming Request is a domain object and not a DTO, If I were you, I would think about how much of Request do I need?

[madtree]

Hi@all,

i'm designing some Service and DAO interfaces for my application at the moment and i'm not sure if it is better to include full domain objects in the signatures or only the identifiers (in my case a long type).

For example:

variant a):

public void changeRequestStatus(Request request, Status status);

variant b):

public void changeRequestStatus(long requestId, Status status);

Status is an enumeration and Request my domain object.

What is considered the better design?
Thx in advance!
-lasse

There is no better design, just pass what you need : the request id (it's a new request) or the whole request object (there is already an existing request and your service need it to perform its operations).

[khote]

be flexible. if Request is a domain object with a getId() method:

public void changeRequestStatus(Request request, Status status) {
    changeRequestStatus(request.getId(), status);
}

public void changeRequestStatus(long requestId, Status status) {
 ....
}

[manifoldronin]

There are a few factors you might want to consider before making this decision, e.g.:
1. Will the service be exposed remotely?
2. Does concurrent modifications to this domain object happen very often? What kind of locking/isolation mechanism are you using?
3. (If you are using hibernate) are you using OpenSessionInView?
4. In a typical usage scenario, how likely/unlikely the client code would have anyway already gotten hold of an instance of the domain object at the point of invoking this service?
5. In order to change the status, would the implementation of this service only need an id (e.g. executing a direct JDBC update)? Or would it always need a full instance (e.g. updating through an ORM tool)?

[sabarish]

After looking at all these responses you would have realized that there's no 1 answer. But if you ask me, usually i would pass in the Request itself. This is because its difficult to predict what all i would need in the near future from the Request. Passing in the object helps prevent frequent changes to the method signature. For ex in this case, you might want to know what the current status is, before you allow a new status to be set etc...

[karldmoore]

After looking at all these responses you would have realized that there's no 1 answer. But if you ask me, usually i would pass in the Request itself. This is because its difficult to predict what all i would need in the near future from the Request. Passing in the object helps prevent frequent changes to the method signature. For ex in this case, you might want to know what the current status is, before you allow a new status to be set etc...

I agree in part. I would sooner pass the object down if its there, but if there are situations where I don't have an instance, its always a pain if you have to fetch one just to pass it in. Also I would also say it depends what the object is, if we were talking about a HttpRequest or something of that ilk and littering the code with it, because I need the sessionId its not a good idea.