2009-02-05 5 views
0

Итак, я работаю над этим приложением на основе веб после Repository модели, подражатель DDD мужлана, используя StructureMap .... бла, бла, бла ...Управление файлами: обрабатывается уровнем доступа к данным бизнес-уровня?

Одним из аспектов приложения позволяет пользователям загружать и управлять файлами.

Где, какой слой должен отвечать за управление сохранением/удалением этих пользовательских файлов?

Бизнес-уровень, или уровень доступа к данным ...?

Оно, по какой-либо причине, не кажется прямой вперед ответ ...

Исторически сложилось так, я просто ударил его в GUI, но стремится быть более programmaticall правильно и переосмысление того, что должно обрабатывать эти услуги. Может быть, я просто ответил на свой вопрос ...

ответ

0

Я бы поместил его в бизнес-уровень, хотя, если бы это был я, я бы в конечном итоге позвонил в DAL в отношении файлов, которые каждый пользователь загрузил. Я бы отслеживал в базе данных имена файлов и местоположения для каждого файла, который пользователь загружает.

+0

Именно так у меня есть это сейчас. Но что-то пахнет фанк .. может быть, просто я не принимаю душ сегодня ... – 2009-02-05 22:00:47

0

Я поместил шахту в DAL, так как мы рассмотрели файлы, в которые нужно обновить или запросить, только через другой «протокол», который является System.IO.

Более конкретно, я создал класс FileManager, который обрабатывал все основы и даже имел пару констант на месте, поэтому было достаточно легко изменить места расположения для среды разработки и производства, поскольку они были совершенно разными.

+0

Таким образом, доказывая, что нет правильного ответа, только тот, который лучше всего подходит для вашего приложения! –

+0

Истинно, я думаю, это зависит от того, что вы хотите определить для взаимодействия с файлом, как с бизнес-функцией или с функцией, связанной с данными. –

0

Dillie-O - Кроме того, если приложение когда-либо переключалось на хранение файлов из ввода-вывода в БД, DAL является более логичным местом. Некоторая гибкость ...

0

Он находится в полной остановке DAL.

Бизнес-логика не должна иметь зависимость от IO в вашей среде.

Вы помещаете его в бизнес-логику, в следующий раз, когда вы захотите использовать эту часть «логики», но в конечном итоге на окружении без разрешения IO файла, вы должны быть тостом.

1

Я создаю отдельный слой «Уровень доступа к хранилищу (SAL)» .... получение информации о файлах из DAL, которую я передал, чтобы SAL и SAL вернули мне правильный файл .... так что если когда-нибудь я переключусь на Amazon web услуги из хранилища веб-хостинга, я просто изменю классы в SAL, подключу DLL и готов к работе .... потому что пользователь будет загружать файл так же, как раньше, поэтому пользовательский интерфейс не изменяется ..... бизнес-правила применяются так же, как и раньше, поэтому BLL не изменен .... База данных не изменилась, и информация о файле сохраняется так же, как и раньше, поэтому DAL не изменяется ...... Единственное, что изменилось, это протокол для доступа к файлу. .. просто измените SAL

+0

Хороший ответ. Для определения интерфейса SAL может быть создана одна DLL, и одна или несколько реализаций могут быть созданы в других сборках для каждого поддерживаемого провайдера, например. LAN, Azure, AWS и т. Д. Изменение одной строки в файле конфигурации может переключить вашу SAL на другого провайдера. Эта конструкция также упрощает модульное тестирование. –