File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Implementing search method in business layer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Implementing search method in business layer" Watch "Implementing search method in business layer" New topic
Author

Implementing search method in business layer

Paweł Baczyński
Bartender

Joined: Apr 18, 2013
Posts: 845
    
  14

Hello. My assignment says:

[The GUI] must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.

So I am wondering which kind of interface to implement.

1.
2.
3.
4.
5.

1 and 2 require a client to send a Map pairing a key (field name) to its value. The second version lacks getAllRooms as it is somewhat redundant (passing an empty Set would mean the same as calling this method).
The main advantage of this approach is that it allows adding new searching patterns easily.
A drawback: its more complicated to implement.

3, 4, and 5 try to do this differently. The requirements ask for search by name/location so it is all the interfaces do. No more. There are some variants but the main idea is the same.
An advantage: easy to implement
A drawback: adding new search criterias would require to add new methods

What is the best? Well, I don't ask you to tell me what to choose.
I just want to know if implementing 3, 4 or 5 could cause me to lose some points (as being hard to modify).


Formely Pawel Pawlowicz
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5147
    
  12

I didn't implement a seperate getAllRooms method.

I don't want to sound harsh, but I don't like any of your interfaces The main reason why I don't like them. I don't like the map, because it lacks compile time safety (your keys could be everything, even case sensitive). I don't like the methods where you have name and location as seperate parameters, because that would require an interface (contract) change if for a new version you have to add an optional date range. Another (minor) reason: you use arrays instead of List.

There is an alternative that gives you the advantage of a map (just 1 parameter, always the same, no matter how many criteria you have) with the advantage of the seperate parameters (compile time safety). I'm curious if you can think of it. And if you can, you'll know how my interface was defined


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 724
I did something similar :


The input criteria is a string like this: [room name, room location, ....]
The searching algorithm is like like :
1. search for room name. if room name is an empty string like this "", all records will be matched.
2. search for room location. If room location is an empty string, all records will be matched.
3. If a match is found for room name and room location is empty , then return all rooms with that name.
4. The same thing for room location.
5. Of course, if name and / or location won't match, it returns nothing.


Paweł Baczyński
Bartender

Joined: Apr 18, 2013
Posts: 845
    
  14

Roel De Nijs wrote:I don't want to sound harsh, but I don't like any of your interfaces

Don't worry. I don't like any of them either. If I felt comfortable with them I wouldn't ask.

Roel De Nijs wrote:Another (minor) reason: you use arrays instead of List.

What's wrong with arrays?

Roel De Nijs wrote:There is an alternative that gives you the advantage of a map (just 1 parameter, always the same, no matter how many criteria you have) with the advantage of the seperate parameters (compile time safety). I'm curious if you can think of it. And if you can, you'll know how my interface was defined

Hmmm. Are you thinking about enums? Something like this?


I think you didn't mean something like this. This would require that a client knows how the service is implemented. Right?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5147
    
  12

Nothing is really wrong with arrays, but a List is easier to work with. In your search method how are you populating your array? Because you have no idea about how many records will be returned. With a List you just create one and add as many elements as you need, without any problem.

Certainly not with enums, that's even worse! What do you think about a specific RoomCriteria class which you can pass to your search method? For now it has 2 properties (name and location). If next week you have to add a date range to your search, you can simply add 2 extra properties to your object (beginDate and endDate), no changes to method signature and update your code on server/client appropriately.
Paweł Baczyński
Bartender

Joined: Apr 18, 2013
Posts: 845
    
  14

Roel De Nijs wrote:What do you think about a specific RoomCriteria class which you can pass to your search method? For now it has 2 properties (name and location). If next week you have to add a date range to your search, you can simply add 2 extra properties to your object (beginDate and endDate), no changes to method signature and update your code on server/client appropriately.

So simple! So obvious! Why did I miss that? ;)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Implementing search method in business layer
 
Similar Threads
NX: URLyBird 1.3.2. Question about the process of booking.
Unable to instantiate default tuplizer [org.hibernate.tuple.entity.PojoEntityTuplizer]
Business Layer, Factory and and Business Layer Search method
URLyBird Search Options
All of URLy Bird 1.1.3 about Junit test