mfp: SysExtension Framework – to the rescue

[mazzy]

Цитата:

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

Но по-моему выгоды от предлагаемого подхода совсем неочевидны.
Что сделал mfp ?... Просто замели под половичок

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

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

[Logger]

Цитата:

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

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

Но ведь это эквивалентно тому что мы явно напишем в коде New ClassNameXXX()
Гибкость теряется.
Вся прелесть в том и была чтобы можно было подправив только конструктор, заставить кучу кода работать по-другому.
См. пример с использованием семейства SysExcel и ComExcelDocument_RU и проблемами которые это повлекло, когда захотели везде в иерархии подменить использование этих классов на наследников работающих через .Net

В такой новой схеме на ax2012 как бы ты реализовал эту задачу ? Может быть есть удобный и красивый вариант ?

[gl00mie]

Цитата:

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

Но ведь это эквивалентно тому что мы явно напишем в коде New ClassNameXXX() Гибкость теряется. Вся прелесть в том и была чтобы можно было подправив только конструктор, заставить кучу кода работать по-другому.

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

Цитата:

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

См. пример с использованием семейства SysExcel и ComExcelDocument_RU и проблемами которые это повлекло, когда захотели везде в иерархии подменить использование этих классов на наследников работающих через .Net. В такой новой схеме на ax2012 как бы ты реализовал эту задачу?

ComExcelDocument_RU в коде приложения везде создается через new, т.е. там вообще не предполагается, что у него могут быть наследники. А что касается SysExcel - там немного другая тема: в нем использован шаблон "стратегия" для создания экземпляров классов, и за счет этого оказалось возможным подменить версию, работающую через COM, на версию, работающую через .NET. Шаблон же "фабрики" в нем можно было бы применить для поддержки различных версий офиса в случае работы через COM, а там вместо этого есть жесткая завязка на определенный перечень версий, зашитый в enum.
Т.е. вызывающий код не знает и не должен знать, с какой версией офиса он работает - это заморочки обертки (SysExcel, например). Но сама обертка знает, с какими версиями офиса она умеет работать, и знает это в куче мест, где по енуму MSOfficeVersion создается тот или иной класс-наследник. Если бы была задача научить ее работать с большим числом версий, то в 2012 это отчасти удобнее было бы делать с помощью новой "фабрики".

[EVGL]

Цитата:

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

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

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

Не пойму: вы [вдвоем] лукавите или всерьез? Вас никогда не раздражало, что приходилось перекрывать конструктор базового класса в текущем слое приложения?