0

所以，我正在开发这个基于存储库模型的基于 Web 的应用程序，一个想要的 DDD 傻瓜，使用 StructureMap....等等等等。

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

应该在哪里、哪一层负责管理这些用户文件的保存/删除？

业务层，还是数据访问层……？

无论出于何种原因，它似乎都不是一个直截了当的答案......

从历史上看，我只是在 GUI 中打了它一巴掌，但努力使程序更正确，并重新思考应该处理这些服务的内容。也许我只是回答了我自己的问题......

4

5 回答 5

2

我创建了一个单独的层“存储访问层 (SAL)”....从 DAL 获取文件信息我将其传递给 SAL，SAL 将正确的文件返回给我....所以如果有一天我从网络托管切换到亚马逊网络服务存储 , 我 将 只 改变 SAL 中 的 类 , 插入 DLL 并 准备 去 .... 因为 用户 将 以 与 以前 相同 的 方式 上传 文件 , 所以 UI 不会 改变 ... ... 业务 规则 与 执行 相同之前所以 BLL 没有改变....数据库没有改变，文件信息和以前一样保存，所以 DAL 没有改变......唯一改变的是访问文件的协议......所以只是更改 SAL

于 2011-08-04T13:15:31.670 回答
0

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

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

于 2009-02-05T21:58:46.093 回答
0

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

于 2009-02-05T22:02:36.630 回答
0

我会把它放在业务层，但如果是我，我最终会就每个用户上传的文件调用 DAL。我会在数据库中跟踪用户上传的每个文件的文件名和位置。

于 2009-02-05T21:56:53.727 回答
0

它在 DAL 句号中。

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

你把它放在业务逻辑中，下次你想使用那个“逻辑”但最终进入一个没有文件 IO 权限的环境时，你会被干杯。

于 2010-12-08T02:16:38.273 回答