文件管理：由业务层的数据访问层处理？
因此，我正在开发这个基于 Web 的应用程序，遵循存储库模型，一个想要成为 DDD 的傻瓜，使用 StructureMap...等等，等等，等等......
应用程序的一个方面允许用户上传和管理文件。
哪里、哪一层应该负责管理这些用户文件的保存/删除？
业务层， 或者数据访问层...？
无论出于何种原因，它似乎都不是一个直接的答案...
从历史上看，我只是将其放入 GUI 中，但努力变得更加编程正确，并重新思考应该如何处理这些服务。 也许我只是回答了我自己的问题......
So, I am working on this web based app following the Repository model, a wannabe DDD dork, using StructureMap.... blah, blah, blah...
One aspect of the application allows users to upload and manage files.
Where, what layer, should be responsible for managing the saving/ deleting of these user files?
The Business Layer,
or the Data Access Layer...?
It, for whatever reason, doesn't seem a straight forward answer...
Historically, I just slapped it in the GUI, but striving to be more programmaticall correct and rethinking what should handle these service. Maybe I just answered my own question...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我创建一个单独的层“存储访问层（SAL）”...从 DAL 获取文件信息我将其传递给 SAL，SAL 返回正确的文件...所以如果有一天我从网络托管切换到 Amazon Web 服务存储，我只需更改 SAL 中的类，插入 DLL 并准备好...因为用户将以与以前相同的方式上传文件，因此 UI 不会更改...业务规则的执行方式与之前所以 BLL 没有改变......数据库没有改变，文件信息的保存与以前相同，所以 DAL 没有改变......唯一改变的是访问文件的协议......所以只是更改 SAL
I create a separate layer "Storage Access Layer (SAL)" .... getting file information from DAL I passed that to SAL and SAL return me the correct file ....so if someday I switch to Amazon web services from web hosting storage , I will just change the classes in SAL , plug the DLL and ready to go ....because the user will upload the file in same way as before so UI is not changed..... business rules are enforced same as before so BLL is not changed....Database has not changed and information of file is saved same as before so DAL is not changed...... only thing changed was the protocol to access the file....so just change the SAL
我会把它放在业务层，但如果是我，我最终会针对每个用户上传的文件调用 DAL。 我会在数据库中跟踪用户上传的每个文件的文件名和位置。
I would put it in the business layer, though if it were me, I'd end up making calls to the DAL with regards to the files each user has uploaded. I'd keep track in the database of the file names and locations for each file a user uploads.
我把我的放在 DAL 中，因为我们考虑了要更新或查询的文件数据，只是通过不同的“协议”，即 System.IO。
更具体地说，我创建了一个 FileManager 类来处理所有基础知识，甚至还设置了几个常量，因此很容易更改开发和生产环境的路径位置，因为它们截然不同。
I put mine in the DAL since we considered the files data in which to update or query, just through a different "protocol" that being System.IO.
More specifically, I made a FileManager class that handled all the basics and even had a couple of constants in place so it was easy enough to change path locations for development and production environments, since they were drastically different.
Dillie-O - 此外，如果应用程序曾经切换到将文件从 IO 存储到 DB，则 DAL 是一个更合乎逻辑的位置。 一定的灵活性...
Dillie-O - Furthermore, if the application ever switched to storing files from the IO to the DB, the DAL is a more logical place. Some flexibility...
这是 DAL 句号。
业务逻辑不应该对您的环境有 IO 依赖性。
你把它放在业务逻辑中，下次你想使用那段“逻辑”但最终进入一个没有文件 IO 权限的环境时，你就完蛋了。
It's in DAL full stop.
Business logic should not have IO dependency on your environment.
You put it in business logic, next time you want to use that piece of "logic" but end up on an environment with no file IO permission you'd be toast.