Neither. Better would be not to use file system directly, but to allow database to handle the files as binary fields, or so called BLOBs.
File systems are not transactional. If you use transactions in your logic and some transaction fails, you can be sure that database has rolled back any changes you have done and you have exactly the state that you had before transactions. If you want to handle files separately, via hooks or via service logic, it can be very hard to provide transaction support, e.g. to implement roll back. For instance, at one step within transaction you delete a record and delete a file in the file system, then in several steps later the transaction fails. For rollback you would need to restore the files deleted within this transaction. This can be a hard task. If you store binary data in BLOB fields, you get transaction support for free, and will always have a consistent state.
Database provide usually functionality to create backups and to restore the state from particular backup image. If you need backups, in case of file system you will need to implement your own tools to create and to restore backups so that database contents is consistent with files in file system. If you use BLOBs, you get it for free, database makes sure that you have consistent state at any time.
You can define different user roles with different permissions, e.g. one role allows user to read and modify data, other role allows only to read data, third role allows to read data but only from several tables, not from all available tables in database. If you use file system, it will be hard to implement such permission system. It will be hard to make sure that only users that have particular role have access to the files. If you use BLOBs, you get permission system for free.