Surely your account and user class are the same from your description.

As for your classes, you'd need to define your program more fully before you can be conclusive about the classes you will need to do the job at hand.

You'll need to consider features, and limitations, validations etc.

Once you've written out all the features, their interactions, you'll have a much better idea of what classes you'll need.

That's a weird way you're using to designing an application heh. Here is how i would go about it if it's a fairly small project. First thing you need to do is layout your requirements. Write down what you're trying to achieve and what features you'd like to create. Go for the essential things only at this point. Than look at limitations and different ways of implementation. How you would organize data. How you would store data. What you will use to validate data. What database to use and etc. I would than draw a high level overview of the database with short explanations for each database entity. Than elaborate on it until you create a pretty decent model. You'd obviously want to have account details (i suggest you use aspnet membership features as this is already done for you). You obviously wouldn't be storing data in your database. However what you will be storing is location to files and possibly some validation data such as checksums for each file. Then go from here. Should be a little bit easier to see the whole picture from this point.

For your final year project, i would imagine you'd be required to write full-blown documentation, requirements, development strategy, development roles, scheduling, unit tests and all of that. As boring as it is, that's how projects get done

thanks very much for the feedback, yes i have done the requirements and am trying to design classes, database and screen flows...i will post more if i get stuck

thanks very much for the feedback, yes i have done the requirements and am trying to design classes, database and screen flows...i will post more if i get stuck

i have just figuered out how to extract info from a file as this could be very useful having name, size, type as i could then sort file by these various properties in a gridview etc

Glad to hear its moving on - as long as the design is sufficiently details the bulk of classes etc should be reasonably obvious - and it should filter quickly down from there.

i think each file will have to have a "FileOwner" so that for example when johnny logs in to his account, there will be a database select statement like:

Select * From File
Where FileOwner = 'johnny'

so that it will display only the files that particular user has uploaded - which means i will have to attach the username to each file uploaded some how (mayb in the database along with file properties).........

Have you done any normalization to your database? If so, this may be a way to make your process better structured. Instead of including Fileowner in your File table, create a 1:N (Many) relationship between File and Account. So you would simply include AccountId in table File. This will be a reference back to the account that is currently logged in.

As always countless ways to to achieve that. If you're storing files you could either store them in a database, or in directories on the server out of general web reach etc.

yep normalisation is a good idea to get rid of duplicates etc, i think i will store the file location to each file in a database; does any1 know a sutible server on which to store the files?

do u mean a relationship where 1 user has many files?

i think i will use "user" instead of "account", i suppose it dosnt really matter unless thats the standard way to call them?