所以，我正在研究这个基于网络的应用程序遵循Repository模型，一个想要使用StructureMap的想要的DDD dork ......等等，等等，等等......
该应用程序的一个方面允许用户上传和管理文件。
哪个层，哪个层应该负责管理这些用户文件的保存/删除？
业务层， 或数据访问层......？
无论出于何种原因，这似乎都不是一个直截了当的答案......
从历史上看，我只是在GUI中打了它，但努力使程序更正确，并重新考虑应该处理这些服务的内容。也许我刚刚回答了我自己的问题...
答案 0 :(得分：1)
我创建了一个单独的图层“存储访问层（SAL）”....从DAL获取文件信息我将其传递给SAL并且SAL返回正确的文件....所以如果有一天我切换到亚马逊网络服务从web托管存储，我将只更改SAL中的类，插入DLL并准备好....因为用户将以与以前相同的方式上传文件，因此UI不会更改.....业务规则是强制执行与以前相同所以BLL没有改变....数据库没有改变，文件的信息保存与以前一样，所以DAL没有改变......唯一改变的是访问文件的协议... 。只是改变SAL
答案 1 :(得分：0)
我会将它放在业务层中，但如果是我，我最终会调用DAL，关于每个用户上传的文件。我会在数据库中跟踪用户上传的每个文件的文件名和位置。
答案 2 :(得分：0)
我把我放在DAL中，因为我们考虑了要更新或查询的文件数据，只是通过一个不同的“协议”即System.IO。
更具体地说，我创建了一个处理所有基础知识的FileManager类，甚至还有一些常量，因此很容易改变开发和生产环境的路径位置，因为它们完全不同。
答案 3 :(得分：0)
Dillie-O - 此外，如果应用程序曾经切换到将文件从IO存储到数据库，那么DAL是一个更合理的地方。一些灵活性......
答案 4 :(得分：0)
DAL完全停止。
业务逻辑不应该依赖于您的环境。
你把它放在业务逻辑中，下次你想要使用那条“逻辑”但最终在一个没有文件IO权限的环境中你就会干杯。