AxeleronЯ упростил немного человеку для понимания, ты слишком правильный.

а вы только в соседней ветке вместе со скайАной терзали бедного человека на части, так ничего же?

AxeleronТам случай дохлый совсем - что человеку не скажи, он все равно станет vNext использовать.

Ну так он же изначально не спрашивал какую технологию выбирать, всего лишь по структуре папок был вопрос.

bald56rusа можно поподробнее? на контролере я бы сделал как то так:

слишком громоздко.

вот здесь есть либа и примеры, как собирать дескрипторы сортировок, фильтров и строить запросы LINQ динамически

https://github.com/kendo-labs/dlinq-helpers

ну и таких решений пруд пруди. по сути каждый их сам себе рисует, велосипедостроение в этом направлении неискоренимо ))

bald56rusВсем привет. подскажите пож. на сколько правильным будет следующее решение:
мне необходимо в моем приложении работать с файловой системой, т.е. создавать файлы, каталоги, проверять наличие файлов, архивировать(для того что бы получить то что было сохранено). я это представляю как создание и реализация данного интерфейса в сервисном слое с необходимым функционалом и вызов в необходимом мне месте. я правильно представляю? заранее спасибо

да, всё правильно. возможно стоит подумать о выносе реализации сервиса для работы с файловой системой отдельно (именно реализацию, а не интерфейс).

bald56rusЯ правильно понял общий принцип???

Да, всё правильно.

bald56rusт.е. я хочу запретить редактирование/удаление операции для случая когда у операции есть "потомки" в виде программ. как это сделать правильно?мне приходит в голову тока следующее: при Get запросе по id получить операцию и проверить наличие "потомков". но есть небольшая загвоздка: в случае отсутствия потомков будет выполнен Get запрос, отобразится "представление", потом будет выполнен Post в этом случае я могу извлечь id из OperationEditModel и опять проверить. но что то мне кажется что это не правильно. заранее спасибо

Рассмотрим:

1. Операции: редактирование/удаление (GET, POST Edit, Delete actions)
2. "Операция" это некий объект в модели данных
3. "Потомок" это некая связь, которую можно добыть через объект "Операция"

Задачи фильтра:

1. Фильтр узкоспециализированный, т.е. применяется не на контроллер, а на конкретные действия
2. Фильтр извлекает из Action Parameters идентификатор операции
3. Фильтр получает объект из репозитория по ID
4. Фильтр проверяет наличие "Потомков"
5. Фильтр принимает решение о выдаче или невыдаче разрешения, и в случае отсутствия разрешения отменяет операцию и возвращает пользователю либо код ошибки, либо редиректит на страницу с информацией об отсутствии разрешения, либо редиректит на простмотр (Index или Details), предварительно передав через TempData мессадж о недоступности операции, который должен быть выведен каким-нибудь блоком в HTML.

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