Validation using single object responsible for handling data file.
Joined: Nov 11, 2005
I'm home at last. I`ve came back from US around two weeks ago after working hard during the summer to pay for my college, buy some new books and ofcourse pay for next step on my certification path All right, I know that nobody is interested in this, he he, so let's get to the point.
I got my assignment serveral days ago and have been thinking about the design, in short, I decided to use RMI, ConnectionFactory - multiple instances of Data, one for each client and singleton class to read from database file.
This class is called DBFileAccess, has synchronized methods (or blocks to decrease impact on performance), as a singleton it holds a reference to the object of DBFileAccess class, the other two members are RandomAccessFile and DBFile.
DBFile is a class that has a reference to the File object and holds information about the file like magic cookie value or index positions for records etc. (DBFile object is not supposed to serve as a cache).
To support flexibility, f.e. files in different formats could be used if necessary, I thought of creating an interface DBFileHelper which declares methods responsible for handling the DBFile object, f.e. validation, getting data from file for DBFile object etc. Creating this interface will leave possibility of different implementations depending on the file format. I`m thinking of creating a DBFileHandler class that implements the DBFileHelper interface and implements it's methods in the way it would be able to handle the file I've been provided with.
As I mentioned one of the methods will perform validation of the file, and here I have a doubt... there are two possibilities:
1). I'm performing validation of the file before I give File object reference to the DBFileAccess object. 2). I'm performing validation of the file after I give File object reference to the DBFileAccess object.
The first one sounds more logical, so let's look at it closer, method could look something like this:
If a file it's valid then we can give a reference to this file object to the DBFileAccess object so we can use it. But... then another client connects to the server, chooses the same file and we have a situation when RAF from DBFileAccess class works on the same file and the RAF from validation method, what leads to very bad things and we don't want it.
It seems I have to choose the other solution. Then the method could look something like this:
Everything would be fine if another client chose the same file, but if it chooses wrong format file it gets complicated, because we set DBFA field to the bad file before we validate it and our good file we worked on is only a memory then.
Solution could look like this, but I'm not sure if I like it:
There's also a possibility when a client chooses a file in the right format that would be positively validated, but with a different data than one we operate on, wow, then I would have a big mess Altough it's probably beyond of the scope of assignemnt, I don't like feeling I'm not doing it perfect.
Anyway, I've been on legs for 19 hours so I may overlooked other solutions, that's all what comes to my mind now, but I wanted to post this message before I go to bed. I would be very appreciated for opinions, maybe someone has a different approach to this issue. If you have comments on the overall design please feel free to speak. Thank you.
Joined: Jul 12, 2004
i have two quetions in mind after taking a quick look..
1> is the validation of the data file is required in the specs??I am feeling that wrting "magic cookie value identifies this as a data file " in specs doesn't mean that validation is required .. thats my interpretation ..i may be wrong.. i will wait for others to join ..
2> How do you know that your applciation will require diffrent file formats or diffrent files in future as database not the relational database approach .If they go for relational database aaproach will it support...what are you doing about the data types and primary key of the schema?? what happen if they change the primary key in future??
I am also having the dynamic schema rightnow and at this moment it can support new fields,new filed lengths.. i have assumed data type as strings for fields...for primary key i am defining the key elements at one place... but the thing worries me is
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs. I am not sure whether i am adhering to this requirement with dynamic schema... I will surely wait for others to put their views on this issues and approach.
SCJP 1.4<br />SCWCD 1.4(91%)<br />Working on SCJD -Bodgitt & Scrapper Constructions...<br /> <br />"It takes 43 muscles to frown & 17 to smile but it doen't take any to just sit there with a dumb look on your face .. Keep Smiling "
Joined: Nov 11, 2005
Thank you for a good input, that made me think about something... if we wanted to consider any possibility new problems would be appearing and appearing... and probably the project would end up as a huge multitierd distributed application with oracle database I just caught myself that I'm trying (and other people too for sure) to do it perfect (which is impossible), to be more precise, we are not only trying to do perfect what we have to do, but we are thinking of doing more, we are thinking about any possible scenario that could take place. I just realized that leads to nothing but frustration, because the spec leaves us a room for individual interpretation, and with our "perfect approach" this could never end. During those last serveral days I read many times: "Keep it simple!", it's hard to accept this sometimes, but what we have to do is to foist our own constraints, everybody has to mark it's own border... and nobody said that's easy.
We can hear voices that spec has too many ambiguous or unclear requirements, yes this is a fact, but if we had a very, very clear spec that wouldn't bring any doubts or questions, everyone's project would be identical, without room for own decisions what is a principle of this assigment. I'm treating this assignment as a learning experience so taking from it as much as possible is a good idea, but there's a point when one have to ask oneself a question, am I not going too far? Nothing is black or white as usual, we have to find the gold mean.
OK, enough of this pseudophilosphical bulls***
Originally posted by Bhavik Patel:
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs. I am not sure whether i am adhering to this requirement with dynamic schema...
I don't want to suggest a "perfect approach" but I would interpret this sentence in an opposite way, I think that having a dynamic schema requires that interface should be designed with the expectation of future functionality enhancements.
As for file validation, I just marked my border, what I'll do is just validating the Magic Cookie value. I know it is as simple as it could be, but in this way (what I'll document in my choices.txt) I'll make sure that this is the one and only valid file that can be used as a data source. Then all problems like f.e. client choosing a file with valid data format but with different data in it are solved. Besides that, file validation, like checking the file size, checking schema etc. is only writing an algorithm, it just proves one knows some simple mathematics.
Does anyone have comments on the validation method (last one) in my previous post?