Показать сообщение отдельно
Старый 18.04.2017, 21:53   #58  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
По долгу службы дорабатываю решение на ASP.NET MVC, где куча кода закрыта в откомпилированных сборках, а для доработки, как раз и придумана возможность подписок, dependency injections на основе Unity и прочие гибкости которые предоставляет местный SDK.

Код большинства "закрытых" сборок предоставлен для ознакомления, и если бы его не было, пришлось бы повеситься. Текущий мой подход:
В класс-наследник, который расширяет какой-то метод, я копирую код из оригинала (чтобы не сломать стандартную логику обработки), и правлю его уже так, как нужно мне.

Это просто очень медленно (раз в пять), работу стандартного кода не оттдебажить по-человечески, куча других неудобств, ну и по сути, не дает никакой гарантии, что при более-менее серьезном апдейте моя кастомизация не полетит к чертям.

Кто, вообще, утверждает, что апгрейды упростятся до уровня 1 кнопки?
Если более-менее серьезная кастомизация, а апгрейд содержит серьезные изменения базового функционала, будут неприятные килочасы по отлавливанию неожиданных багов. Причем в рантайме, а не на этапе компиляции.

И все это счастье еще надо уметь готовить. Программировать по-новому, с ограниченными возможностями, тоже надо уметь. Это как сознательно себе выколоть глаза и пытаться заменить их другими органами чувств. Я думаю, программировать с помощью азбуки брайля тоже можно научится - врядли только это будет эффективно.
За это сообщение автора поблагодарили: Sancho (2), mazzy (2), gl00mie (2).