B&S DB interface - should I use it?

[Jarek Losice]

Hello there!

B&S 2.1.1

With my assignment I received the DB interface to be implemented. One of the assignment objectives is to deliver Data class which implements given DB interface. That's clear to me. But what if I deliver my Data class implementation, but my server (and GUI) will use some other class which will dispatch the logic to the same place as Data class, but would have a different - more object oriented - interface?

Why? For example, DB interface has its search method contract described. The GUI description clearly states, that search should be performed in a different way than it is described by the DB interface, so my conclusion is that I can't just simply use DB interface, I need something different.

What do you think?

Thanks,

Jarek.

[Roel De Nijs]

Hi Jarek,

you could create your own interface, extending the given db interface and add another find-method implementing the logic that's required by the gui. and use that method in your program, but i think you should implement all methods from the given interface.

I did something similar: I added another find-method to my own interface which was returning the record numbers and the record string arrays (instead of only the record numbers). And i used that method in my program. But it had the same logic as the find-method described in the given interface and i filtered the records in my gui to only show the exact matches.

Kind regards,
Roel

[Jarek Losice]

Roel,

thanks for your prompt reply. Great idea, I think i will do something similar, it makes sense !
Best regards,

Jarek

[Yucca Nel]

I would like to ask having done B&S why you would not want to implement the interface provided. This is the easiest part of the application development as it does a lot of the desicion making for you...

My interface provide multiple functions, justifying the use of a facade in Data. Justifying the need to assign record numbers to records as it deals with recNo. Justifying the need to not use
synchonization (a heavyweight process) and use a LockManager. From here you have many arguments that count for you in your design choices. Like why did you use RMI vs sockets? I justify my desicion by the fact that the implementation if provided for the lock and unlock methods gave me code that can be reused by rmi if implemented correctly.
etc etc.

[Jarek Losice]

Yucca,

thanks for good questions. I think I need to rethink my server architecture and do a lot of refactoring.
Your questions made me think about the whole thing, and point my weaknesses.

Best regards,

Jarek.

[Björn Wessman]

Hi Jarek,

Since I haven't had my application evaluated yet, I can't guarantee that my solution is correct. But here's what I did:

I implemented the interface methods in my Data class according to their contract. Then I made a facade class that works towards the Data class. All accessing of the Data class' methods goes through this facade. In the Facade class, I implement a find method which invokes the find method in the Data class and then filters all the records that are exact matches and return them in a collection of value objects (I used the record indexes returned in the first find to get the records cached as value objects in my Data class).

So basically, I do the search in two steps. It might not be the best choice for performance, but it doesn't break any interface contract and if I later on get a request to support partial matching of criteria, I haven't constrained the implementation in the Data class to only support exact matches. I'd just change or overload the find method in the facade class to support the new requirement.