0
votes

I am building a window service that monitor folders and transfer files(data with attachments) like dropBox.
I want to build it with N-tier design.
* Is it OK to design the DATA layer to push the data to the BLL ?
* Can a Data layer have some logic with filesystemWatcher that monitor the folder gets the created file and pass it to BL, isn't the BLL call the data layer and not the other way around ?

2

2 Answers

1
votes

Typically, a data access/repository layer abstracts access to an underlying data source. It should be as thin as possible, preferably limited to handling anything related to the persistence of data. From what you've described, it doesn't sound like you have any of that.

Instead, I'd build a series of service classes (not to be confused with Windows services) that are responsible for handling the different types of business logic associated with the file system monitoring that you're trying to do. You can have one service that monitors folders and another service that is responsible for transferring the files. You can then build a layer on top of those service classes that is responsible for coordinating the different operations.

Does that make sense?

0
votes

DAL is there to persist your application state. It is solution to a technical problem of memory unreliability, and so on.

Filesystem is external system, you cannot assume it belongs to and only to your app. You cannot embrace its state, and say it belongs solely to you.

That's why, you communicate with it, and ask anything you need. You can ask it to notify you when something interesting happens (FileSystemWatcher). And then you can act accordingly (transfer files).

So, monitoring files is definitely not DALs responsibility. It would probably be some daemon which monitors filesystem, and then passes work to 'BL'.