Data class and facade

[Pieter Jacobs]

Hi guys (and gals),

I am not even sure what to specify in the subject field, but anyway:

I used the facade pattern; from the Data class I have a FileAccess class and Locking class (not these name though). Within the FileAccess class I do all data file manipulation, and the Locking class handles the Locking and Unlocking. Now, how did you guys handle the following:

I need to check from the Locking class whether a record exists in that data file as well as if the record is deleted or not. Personally I feel it should be checked within the FileAccess class and not within the Locking class - am I right in saying this?

Anyway, I hope the question makes sense.

Pieter

[Vlad Djordan]

Hi Pieter,

I need to check from the Locking class whether a record exists in that data file as well as if the record is deleted or not. Personally I feel it should be checked within the FileAccess class and not within the Locking class - am I right in saying this?

Delegating the workload of your Data class to a FileAccess and Lock class is good design, however, I don't believe the Lock class should know anything about the FileAccess class and vice versa.

In my implementation, much like yourself, I used a form of FileAccess to load the data from the file, but all of my implementation, including locking/unlocking is done within the Data class. I certainly could have taken the approach of using a LockManager, but decided against it.

Either solution is fine, but I think if your LockManager knows about the FileAccess and vice versa, that wouldn't be considered the best design. You should try and figure out a way to maintain the locking/unlocking in the LockManager/Data and leave the FileAccess to just what the name suggests, file access.

Cheers,

Vlad

[Roel De Nijs]

Hi Pieter,

My first thought was also to seperate access from locking, but after a lot of thinking I decided not to do it and just use the Data class which accesses the database file and (un)locks the records. And one of the reasons was the same problem as you encounter. Seperating the Data functionality in 2 classes is because you have high cohesion (with all its advantages), but if you need a call from LockingManager to FileAccess (or vice versa) you have thight coupling (which is considered not so good).
Another reason was I feared a deadlock, but I think that was just because I wasn't too familiar with locking at that moment. If you simply lock on the Data class and have 1 instance of each class deadlock can't occur.

Kind regards,
Roel

[Andriy Pererva]

Hi guys,
My Data class is also a facade, and it contains DBFileAccess and ReentrantLockingManager instances to handle the corresponding tasks.
I this case I decided to add a service to DBFileAccess for record availability checking:

	boolean checkRecordExistence(int recNo, boolean throwRNFE) 
			throws RecordNotFoundException {
		boolean result = false;
		if (recordsCacheMap.containsKey(recNo) &&
				!deletedRecordsQueue.contains(recNo)) {
			result = true;
		} else if (throwRNFE) {
			throw new RecordNotFoundException("Record #" + recNo + " is not found!");
		}
		return result;
	}

Because my DBFileAccess and ReentrantLockingManager know nothing about each other (so can be separately unit-tested), all the checking logic performed in the Data class, which makes it a kind of "thick facade" :-)

[Pieter Jacobs]

Hi guys,

Thanks a lot for the feedback! Roel, did you make the Data class a Singleton or am I understanding it wrong?

Thanks buds,
Pieter

[Roel De Nijs]

Pieter Jacobs wrote:Roel, did you make the Data class a Singleton

The main characteristic of my application is simplicity so my Data class is indeed a singleton (with all methods synchronized).

Kind regards,
Roel

[Pieter Jacobs]

Hi Roel,

Thanks for the feedback.

Enjoy your evening,
Pieter

[Pieter Jacobs]

Hi guys,

Is it still considered good design if I:
Keep the Data class, and then from the Data class checks if the lockCookie is valid in the LockManager class, and then if so, pass control to the FileAccess class?

Basically I would like to check things in the LockManager class and the FileAccess class from the Data class, and then depending on the outcome pass control to the correct class thereafter.

Thanks.
Pieter

[Roberto Perillo]

Howdy, Pieter!

Is it still considered good design if I:
Keep the Data class, and then from the Data class checks if the lockCookie is valid in the LockManager class, and then if so, pass control to the FileAccess class?

Hum... in this case, you are going to have some logic in the Data class, right? Well, this isn't really something to be handled in a Facade, which should be kept thin. I'd say that this kind of logic should be placed in your FileAccess class.

[Pieter Jacobs]

Hi Roberto,

Cool thanks, this confirms my thoughts!

Have a great weekend!
Pieter