"Нужна возможность замены любых классов и методов целиком" Снизит ли это трудоемкость в долгосрочной перспективе?

[ax_mct]

Цитата:

Сообщение от S.Kuskov

А чем эта "замена любых классов и методов целиком через конфигурационные файлы" отличается от механизма слоёв в аксапте?
Замену нужно поддерживать в рантайм?
Количеством слоёв?
Как мержить два решения заменчющих оди и тот же класс, метод?

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

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

Замену нужно поддерживать в рантайм, но при наличии скомпилированной сборки CIL это ничего не стоит.

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

Но вопрос еще и в том хочет ли MS быть эдаким супер-партнером (Крысиным королем) который колбасит и колбасит новый фунционал и устанавливает эти обновления когда и как ему захочется. Тут и решения на extensions не дают стабильности.

При нахождении on-premise когда как я понимаю не может быть автоматических обновлений (или может?) действительно самое простое это позволять overlayering в старом добром стиле.