Pull to refresh

Comments 8

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

Хотелось бы почитать увидеть что-то новое или приближённое к жизни, т.к. примеры с кэшированием, логгированием и валидацией аргументов ну совсем уж избиты. Ещё интересна критика PostSharp'а (кажется, кто-то из хабраюзеров недолюбливает продукт). Сам бы написал статью, да не уверен в своих суждениях пока.
Расскажите, как мне протестировать:
[Tracing, WriteToDatabaseEachTransaction, CheckHistory]
int Salary{ get; set; }

Если всё написано в длинной форме, то всё просто. DatabaseEngine инжектится откуда-нибудь извне, вполне хорошо замещаетя моком. Всё тестируемо.

Если же у меня постшарп. Как мне передать внутрь аспекта мок базы данных?
Ну тут все зависит от того, что из себя представляет WriteToDatabaseEachTransaction. Поскольку в данном примере это написано чтобы у читателя разгулялась фантазия и чтобы читатель сам придумал решение для своих задач. Но тестирование можно проводить как внутри аспекта, так и снаружи, во время доступа к методам, полям и прочим сущностям, которые обработаны аспектами. В общем проблемы не вижу
Просто я когда пытался играться с постшарпом так и не смог понять, как именно его использовать не в игрушечных примерах.

Например у меня есть какой-либо IoC контейнер. Каким образом его запихнуть внутрь аспекта?
У меня получилось только написать статический класс, из которого этот контейнер брался аспектом. Это было неудобно тестировать, это потенциально опасно.

Более того, тестирование готового кода начало превращаться в некоторую головную боль, поскольку аспекты в зависимости от самого класса никак не декларировали какие именно интерфейсы они используют и что надо подменять.
Дороговато выходит этот PostSharp — 15000 долларов на 50 разработчиков.

К тому же, если весь код давным давно написан и отлажен, то переход на него выльется в рефакторинг всего проекта. Кому это надо?
15000 долларов — это оплата 3 дней работы 50 разработчиков. Рефакторинг проекта такого масштаба может занять очень много ресурсов. Например, в задачах, решаемых программой — муторных задачах — из проекта в проект, выйдет что работники потратят очень много времени, гораздо больше 3 дней. Т.е. при рефакторинге более 3 (+ 3 на написание кода postsharp классов) дней, труд разработчиков начнет проигрывать. Покупка продукта выгоднее
я имею ввиду что рефакторинг огромного проекта вручную будет более тяжелым чем использование PostSharp в аналогичных задачах
Only those users with full accounts are able to leave comments. Log in, please.