Not really sure where to go here. Currently i have little to no plan to use a database for this project. The idea is that the site admin can upload and remove images to be displayed in a gallery type situation. Based on the current list of files in the images
directory, thumbnails and mobile sized images will be built if they don't exist for each of the directorys in the "gallery" folder. Image category menu's will be built based on the folders that exist in the folder gallery.
So.. i am wondering if without a database should i create a model that defines files or just use the filesystem object.
Thoughts here are very welcome. (I am also wondering about the need to build a database for this, current thinking is no, just read the filesystem. - open to suggestions etc...)
You are certainly asking an interesting question that blurs the lines a little from specific defintions into more philosophical definitions. As an architect, I find these questions to be the most interesting. If I were architecting this, I'd consider the
filesystem as my model as that is the content that you are performing CRUD operations on. Datamodel doesn't necessarily have to be database, that is just the most common. Technically model could be all session or application objects, or filesystem, or whatever.
I'd probably implement some helper classes to handle all of the filesystem operations so that your business layer can still focus on the simple tasks of requesting CRUD operations without actually performing them. Those helper classes could be considered
your "Data Layer" as they will handle all file create/read/update/delete operations on the files taking file paths as parameters and returning file paths to the business layer.
All that said, if this application is to be nothing more than a simple gallery of uploading, viewing and deleting files, this approach is just fine. If, however, you want some mechanism to search, you might find it difficult to do this. While you could
search based on folder names and the like, you will probably have some performance issues as file system operations are pretty slow when there's many of them.
"Dream as if you'll live forever, live as if you'll die today." --James Dean
I agree with @AceCorban, even if you are not talking to a Database you still need a Model. A Model isn't tied to a database or a specific data access technology. The model is meant to be a way to encapsulate data and send the data between different parts
of the system.
I think it is essential to have a Model in the MVC app, even if it's just used as a container to move data between the different segments of the system. For you application instead of reading the contents of a fodler directly, I would read it and place it
into a Model that represents folders and I can then pass that object around, I can build an abstraction layer around this as well. So for example I would have a different project act as a business layer that is reponsible for getting that data from the file
system, populating objects and giving it to mvc. This is really powerful because MVC in this case doesn't know or care about where my data is stored. For example I can have it be on the local file system of the server itself to start , then later modify it
to use an Amazon S3 bucket in the cloud. I can move my content easily to the cloud without making any code changes to my MVC site, just a minor configuration chance. It's much more versatile like this.
In terms of needing a database or not, that depends on your application, it might be faster to query data from a database rather than parsing through all the files in the file system. If the images have meta data associated with them (username, upload time)
etc that might be a good candiate for data in a database. Lastly, this type of system might benefit from a NoSql solution such as RavenDB or MongoDB, so you might want to consider those data stores as well.
Beautiful! I think that is about exactly what i was looking for. From discussing this with my friend who i am building this for (as an excuse to get used to the mobile framework) I don't think he is looking for any thing that would force him to describe
the image he is uploading and that the images will do all the speaking. So i was having one of those moments. :)
My understainding is that the number of images he wishes to display in each folder is limited, as is the number of folders. I am still 1/2 way tempted to build a simple db to store filenames and paths, but the idea is that at any time he can ftp in and remove
or add files and using the filesystem seemed to offer a more dynamic choice.. If there is no image, don't bother displaying thumbs. Othewise he would potentially need to "update the catalog" when he changed content or the site would need to "reconcile" with
the database everytime someone entered it.
I am personally leaning on the easier option of just using the filesystem. If it turns out to degrade performance too much i think i can always add the database after the fact.
I am personally leaning on the easier option of just using the filesystem. If it turns out to degrade performance too much i think i can always add the database after the fact.
That works and it might be a good idea to get something like this up and running quickly so your friend can see it. As long as you seperate out concerns via a business layer, you should be ok. If you need to change storage later, you can do that easily.
For now the file system sounds like the way to go.
Well, I still think it would help to have a class or classes to specifically handle file operations, that way if requirements change in the future (in my experience, they typically do), you can always add to those functions to perform db operations and syncing
functions later. If nothing else, they serve as a placeholder for this potential.
Good thoughts though. Your head is certainly in the right place.
"Dream as if you'll live forever, live as if you'll die today." --James Dean
Add a model that defines the properties of the file (maybe not much more than filename and possibly path)
Add a class (or classes) to handle all actions like generating a list of files based on path, resizing images to support the different resoultions etc.
To some level like the authorization and membership modules of asp.net
This would then allow me to change the location/datastore easily later.
Roblem
Member
104 Points
70 Posts
MVC without the M?
Aug 03, 2012 05:05 PM|LINK
Not really sure where to go here. Currently i have little to no plan to use a database for this project. The idea is that the site admin can upload and remove images to be displayed in a gallery type situation. Based on the current list of files in the images directory, thumbnails and mobile sized images will be built if they don't exist for each of the directorys in the "gallery" folder. Image category menu's will be built based on the folders that exist in the folder gallery.
So.. i am wondering if without a database should i create a model that defines files or just use the filesystem object.
Thoughts here are very welcome. (I am also wondering about the need to build a database for this, current thinking is no, just read the filesystem. - open to suggestions etc...)
bbcompent1
All-Star
33873 Points
8776 Posts
Moderator
Re: MVC without the M?
Aug 03, 2012 05:16 PM|LINK
I would think reading the filesystem would probably be the easiest and cleanest way to do it IMHO :)
Roblem
Member
104 Points
70 Posts
Re: MVC without the M?
Aug 03, 2012 05:18 PM|LINK
thanks.. it is the way i am leaning.. So do you see a need for a model of just a view and controller?
AceCorban
Star
12584 Points
2318 Posts
Re: MVC without the M?
Aug 03, 2012 05:18 PM|LINK
You are certainly asking an interesting question that blurs the lines a little from specific defintions into more philosophical definitions. As an architect, I find these questions to be the most interesting. If I were architecting this, I'd consider the filesystem as my model as that is the content that you are performing CRUD operations on. Datamodel doesn't necessarily have to be database, that is just the most common. Technically model could be all session or application objects, or filesystem, or whatever.
I'd probably implement some helper classes to handle all of the filesystem operations so that your business layer can still focus on the simple tasks of requesting CRUD operations without actually performing them. Those helper classes could be considered your "Data Layer" as they will handle all file create/read/update/delete operations on the files taking file paths as parameters and returning file paths to the business layer.
All that said, if this application is to be nothing more than a simple gallery of uploading, viewing and deleting files, this approach is just fine. If, however, you want some mechanism to search, you might find it difficult to do this. While you could search based on folder names and the like, you will probably have some performance issues as file system operations are pretty slow when there's many of them.
CodeHobo
All-Star
18669 Points
2648 Posts
Re: MVC without the M?
Aug 03, 2012 05:29 PM|LINK
I agree with @AceCorban, even if you are not talking to a Database you still need a Model. A Model isn't tied to a database or a specific data access technology. The model is meant to be a way to encapsulate data and send the data between different parts of the system.
I think it is essential to have a Model in the MVC app, even if it's just used as a container to move data between the different segments of the system. For you application instead of reading the contents of a fodler directly, I would read it and place it into a Model that represents folders and I can then pass that object around, I can build an abstraction layer around this as well. So for example I would have a different project act as a business layer that is reponsible for getting that data from the file system, populating objects and giving it to mvc. This is really powerful because MVC in this case doesn't know or care about where my data is stored. For example I can have it be on the local file system of the server itself to start , then later modify it to use an Amazon S3 bucket in the cloud. I can move my content easily to the cloud without making any code changes to my MVC site, just a minor configuration chance. It's much more versatile like this.
In terms of needing a database or not, that depends on your application, it might be faster to query data from a database rather than parsing through all the files in the file system. If the images have meta data associated with them (username, upload time) etc that might be a good candiate for data in a database. Lastly, this type of system might benefit from a NoSql solution such as RavenDB or MongoDB, so you might want to consider those data stores as well.
Blog | Twitter : @Hattan
Roblem
Member
104 Points
70 Posts
Re: MVC without the M?
Aug 03, 2012 05:54 PM|LINK
Beautiful! I think that is about exactly what i was looking for. From discussing this with my friend who i am building this for (as an excuse to get used to the mobile framework) I don't think he is looking for any thing that would force him to describe the image he is uploading and that the images will do all the speaking. So i was having one of those moments. :)
My understainding is that the number of images he wishes to display in each folder is limited, as is the number of folders. I am still 1/2 way tempted to build a simple db to store filenames and paths, but the idea is that at any time he can ftp in and remove or add files and using the filesystem seemed to offer a more dynamic choice.. If there is no image, don't bother displaying thumbs. Othewise he would potentially need to "update the catalog" when he changed content or the site would need to "reconcile" with the database everytime someone entered it.
I am personally leaning on the easier option of just using the filesystem. If it turns out to degrade performance too much i think i can always add the database after the fact.
Rob
CodeHobo
All-Star
18669 Points
2648 Posts
Re: MVC without the M?
Aug 03, 2012 06:05 PM|LINK
That works and it might be a good idea to get something like this up and running quickly so your friend can see it. As long as you seperate out concerns via a business layer, you should be ok. If you need to change storage later, you can do that easily. For now the file system sounds like the way to go.
Blog | Twitter : @Hattan
Roblem
Member
104 Points
70 Posts
Re: MVC without the M?
Aug 03, 2012 06:15 PM|LINK
Thank you all for your input!
AceCorban
Star
12584 Points
2318 Posts
Re: MVC without the M?
Aug 03, 2012 06:23 PM|LINK
Well, I still think it would help to have a class or classes to specifically handle file operations, that way if requirements change in the future (in my experience, they typically do), you can always add to those functions to perform db operations and syncing functions later. If nothing else, they serve as a placeholder for this potential.
Good thoughts though. Your head is certainly in the right place.
Roblem
Member
104 Points
70 Posts
Re: MVC without the M?
Aug 03, 2012 06:46 PM|LINK
Ok... so current thinking..
Add a model that defines the properties of the file (maybe not much more than filename and possibly path)
Add a class (or classes) to handle all actions like generating a list of files based on path, resizing images to support the different resoultions etc.
To some level like the authorization and membership modules of asp.net
This would then allow me to change the location/datastore easily later.
R