File 文件管理：由业务层的数据访问层处理？

因此，我正在使用StructureMap，按照存储库模型（一个想要的DDD dork）开发这个基于web的应用程序。。。。废话，废话，废话

应用程序的一个方面允许用户上传和管理文件

何处、哪一层应负责管理这些用户文件的保存/删除

业务层， 还是数据访问层

不管出于什么原因，这似乎不是一个直截了当的答案

---

从历史上看，我只是在GUI中添加了它，但我努力做到更加正确，并重新思考应该如何处理这些服务。也许我只是回答了我自己的问题…

我会把它放在业务层，不过如果是我，我会就每个用户上传的文件给DAL打电话。我会在数据库中记录用户上传的每个文件的文件名和位置。

我将我的文件放在DAL中，因为我们考虑了要更新或查询的文件数据，只是通过一个不同的“协议”，即System.IO

---

更具体地说，我创建了一个FileManager类，它处理了所有的基础知识，甚至有几个常量，因此很容易为开发和生产环境更改路径位置，因为它们有很大的不同。

Dillie-O-此外，如果应用程序切换到将文件从IO存储到DB，DAL是一个更符合逻辑的地方。一些灵活性…

这是一个句号

业务逻辑不应该对您的环境具有IO依赖性

---

如果你把它放在业务逻辑中，下次你想使用这段“逻辑”，但最后却进入了一个没有文件IO权限的环境，那你就完蛋了。

我创建了一个单独的层“存储访问层（SAL）”。。。。从DAL获取文件信息我将其传递给SAL，SAL返回正确的文件…因此，如果有一天我从web托管存储切换到Amazon web服务，我只需更改SAL中的类，插入DLL并准备就绪…因为用户将以与以前相同的方式上载文件，因此UI不会更改。。。。。业务规则的执行与以前相同，所以BLL没有更改…数据库没有更改，文件信息保存与以前相同，所以DAL没有更改。。。。。。唯一改变的是访问文件的协议…所以只需更改SAL

，从而证明没有正确的答案，只有最适合您的应用程序的答案！是的，我想这取决于你想将文件交互定义为什么，业务相关的函数还是数据相关的函数。这正是我现在所拥有的。但是有些东西闻起来很怪。。也许只是我今天没洗澡…好答案。可以创建一个DLL来定义SAL接口，并且可以在其他程序集中为每个受支持的提供程序（例如LAN、Azure、AWS等）创建一个或多个实现。更改配置文件中的一行可以将SAL切换到其他提供程序。这种设计也使单元测试变得更容易。