When you’re writing a massive application, if given a choice to use a file manager to manage files or to allow the application to manage the files on its own, it’s much preferable that allow the application to handle the file placement logic. This way, the application’s database can be put in charge of maintaining the file locations ensuring that there are no conflicts and that there is a centralized location to find everything. When an application is maintaining the files, there isn’t even a need for a descriptive name to a file, since all relevance will be maintained by the database. Since you’re only interacting with the files through the application, the application can ensure that the file exists, the file won’t be overwritten, and upon deletion, there are no dependencies on this file.<\/p>\n
In the case of major applications, where it’s possible for many components to have access to the same files, I recommend that all these interactions be performed through a centralized file management core. This way, if we were to change the file management logic, it can be easily performed at a single location.<\/p>\n","protected":false},"excerpt":{"rendered":"
When you’re writing a massive application, if given a choice to use a file manager to manage files or to allow the application to manage the files on its own, it’s much preferable that allow the application to handle the file placement logic. This way, the application’s database can be put in charge of maintaining … <\/p>\n