mfp: SysExtension Framework – to the rescue

[gl00mie]

Цитата:

Сообщение от Logger

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

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

Цитата:

Сообщение от Logger

Или внесение кастомизаций в Классфактори не запрещено, так что мы для переданного значения атрибута все же сможем подсунуть другого наследника ?

Теоретически можно покорежить фабрику SysExtension, но это порушит всю идею. Это все равно что в код зашивать

if (trans.AccountNum == "ИП Пупкин") {...} else {...}

Цитата:

Сообщение от Logger

Кстати, неявная связь - атрибут - наследник все равно есть. Перекрестные ссылки её позволяют отследить?

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

Цитата:

Сообщение от mazzy

в реальном мире и в мире кастомизаций выбор подкласса зависит от кучи параметров. кроме того, далеко не очевидным способом.

По-моему, это зависит от того, где располагается точка принятия решения: если клиентский код сам не знает, чего хочет, и решение отдано на откуп "умному" методу-фабрике, который неочевидным образом выбирает нужный подкласс, тогда да, указанный подход не работает, потому что фабрика SysExtension лишена искуственного интеллекта и знаний, специфичных для той или иной иерархии классов. Если же у клиентского кода есть ясность относительно того, что он хочет получить, то таких проблем не возникает.

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

Цитата:

Сообщение от mazzy

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

Как мне представляется, есть определенная проблема, даже две:

• сложность подъема кастомизаций при обновлении (сюда относится и накатывание обновлений стандартного приложения, и перенос модификаций на новый SP/CU/Rollup)
• сложность скрещивания разных решений в одном слое

Для решения этих двух проблем, как мне представляется, и был затеян целый ряд архитектурных изменений в 2012-й. Если следовать предложенному пути с той же SysExtension, то можно лепить кастомизации сбоку, чуть легче их поднимать на новые SP, автоматически накатывать исправления стандартного приложения и меньше беспокоиться, что разрабатываемое решение будет очень сложно скрестить с другими решениями в рамках одного слоя приложения. Разумеется, для решения других проблем эти архитектурные изменения либо подходят плохо, либо вовсе не годятся, но, по-моему, никто не утверждал, что SysExtension - это "серебряная пуля".