0

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...

shilovk
  • 11,718
  • 17
  • 75
  • 74

5 Answers5

2

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

Rameez Usmani
  • 135
  • 1
  • 8
  • 1
    Good answer. One DLL could be created to define the SAL interface, and one or more implementations could be created in other assemblies for each supported provider, e.g. LAN, Azure, AWS, etc. Changing one line in a configuration file could switch your SAL to a different provider. This design also makes unit testing much easier. – Michael Csikos Nov 27 '16 at 21:39
0

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.

Sleeper Smith
  • 3,212
  • 4
  • 28
  • 39
0

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.

Nick DeVore
  • 9,748
  • 3
  • 39
  • 41
  • That is precisely how I have it now. But something smells funky.. maybe just me not taking a shower today... –  Feb 05 '09 at 22:00
0

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
  • 29,277
  • 14
  • 101
  • 140
  • Thus proving there's no right answer, just the one that best fits for your application! – Nick DeVore Feb 05 '09 at 22:00
  • True true, I guess it depends on what you want to define the file interaction as, a business related function or a data related function. – Dillie-O Feb 06 '09 at 00:02
0

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...