Эволюция сервисных методов

Сложность по шкале Microsoft 200-300

Давно хотел изложить свои мысли по поводу эволюции сервисных методов, но до последнего момента правильная, на мой взгляд, идея имела плохую реализацию – слишком трудоемкую и развесистую. На данный момент я пришел к некоторому сокращению кода и готов поделиться мыслями по поводу эволюции сервисных методов. Сразу скажу, что речь пойдет о доменных сервисах по обработке данных, так как чаще всего именно они занимаются обработкой данных в течение продолжительного времени. Однако описанные подходы наверно можно применять и к другим классам с «долгоиграющими» методами.

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

Простейшие

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

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

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

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

Подробнее

ObjBin Cleaner Service

Давно хотел сдеалать программку, которая бы на регулярной основе проверяла папку с проектами и удаляла оттуда автогенеренные папки типа obj и bin, дополнительно все, что нагенерит там ReSharper и папки TestResults. Для кого-то это может и не проблема, но при наличии в разработке нескольких достаточно крупных проектов это становится проблемой, все это может занимать до 2 гигов, к примеру, как у меня. Можете себе еще представить ситуацию, когда на одной машине работает несколько человек, у каждого своя папка с проектами и после завершения сеанса работы не происходит очистки этих папок. Как-то раз, чистя такие вот станции мы обнаружили, что в таких папках было 60 гигов! Таким образом полезность утилиты, которая бы все это каждодневно удаляла – очевидна.

Для этой цели я задумал использовать Windows Service. Некоторые говорят, что легче написать батничек, но я этой магией не владею и ковыряться не хотелось, Windows Service мне показалось более заманчивой перспективой в плане получения новых знаний.

Подробнее