AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.03.2016, 00:06   #41  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от fed Посмотреть сообщение
Вообще - я думаю что для микрософта первые года два DAX в Cloud будут шоком. Очень они много нового и интересного узнают о том как на самом деле делаются проекты, за что на самом деле клиент платит партнеру, много ли клиентов готовы переносить данные в облако и действительно ли клиенты готовы оплачивать накладные расходы на ведение разработки 'по правильному'. Это уже не говоря про ценовую политику и другие чисто коммерческие вещи.
В общем - Микрософт следует своему знаменитому корпоративному лозунгу "Слабоумие и отвага"...
Потому все и ждут он-прем, потихоньку делая разработку на демо-виртуалках
Тем более, что апгрейда с предыдущих версий нет, клауд сейчас только для новых внедрений.
__________________
--
regards, Oleksandr
Старый 06.03.2016, 00:07   #42  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от belugin Посмотреть сообщение
Слои остались, но не уверен, что в клауде это разрешат делать, в on prem скорее всего будет
Никаких ограничений на использование слоев нет, более того, кодов доступа тоже нет. Возможно, пока...
__________________
--
regards, Oleksandr
Старый 06.03.2016, 09:57   #43  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Logger Посмотреть сообщение
Он как-то упустил из виду что подготовка такого кода намного дороже и не всякий клиент согласен и способен платить разницу.
Сложно продать BMW, когда клиент хочет автоваз.
Ну как раз основная идея что для клиента это все будет намного проще
Т.е. представьте идею – вам нужно решение, например для склада. Вы заходите в каталог решений Azure, выбираете нужное решение(ну или вообще стандарт) и уже через несколько часов у вас разворачивается решение доступное по URL. Далее в LCS вы отмечаете нужные вам бизнес-процессы, сразу получается список шаблонов для начальных данных, которые нужно заполнить и загрузить в систему чтобы начать работать. В то же время ваши пользователи используя таск гайды по данным бизнес-процессам смогут сразу начать работу или обучение в системе. Платите вы от 50-200 долларов за человеко-месяц. Нужно больше или меньше пользователей – просто добавляете, не думая о конфигурациях, аосах, SQL и прочих вещах, которые большинству пользователей то не очень интересны. Т.е. это все довольно круто в концепции
Но тут опять же надо смотреть детали реализации 
Старый 06.03.2016, 13:37   #44  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
А на чем в этой схеме заработает консалтинг ?
Старый 06.03.2016, 14:30   #45  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Logger Посмотреть сообщение
А на чем в этой схеме заработает консалтинг ?
Я так понимаю - процесс движется к идее, заложенной в MS Dynamics CRM, MS Office, MS Windows. Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код) и останутся dll-ки, к которым можно будет писать свои add-оны.
Ведь по большому счету никто же не посягает на исходные коды Excel, Word - все ими пользуются и пишут в отдельных случаях макросы (=add-оны).
Тот же Excel имеет набор пакетов расширений (Пакет анализа, поиск решения и т.д.). И также этими инструментами (Office, Windows) клиенты пользуются для бизнеса. И даже есть Project, который рассчитывает проекты и ему все верят - что задачи надо делать именно в том порядке, в котором он рассчитал. И никто не просит "подправить формулу для моего проекта, т.к. он супериндивиуален".

В этом ключе - все действия MS разумны и логичны. Dynamics будет в роли "мегакалькулятора" и в рамках этой роли конечно логично предъявлять жесткие требования к качеству реализации кода. Документацию напишут - тут вопрос за MS-ом, но после 2012 уже так приятно стало смотреть MSDN (Technet) и знать, что там скорее всего есть ответ.

Единственное, в чем пока остается неясность - так это в популяризации Dynamics. Конкуренция все-таки так или иначе на рынке ERP-систем присутствует и с российским менталитетом "мегакалькулятор" может на российском рынке проигрывать либо неконкуретной любимой программе бухгалтера , либо какой-нибудь немецкой программе, в которую легче внести изменения . Конечно если только не применить демпинг.
Без популяризации будут золотыми специалисты по системе, да и их будет не хватать.

Консалтинг здесь будет зарабатывать видимо "ассортиментом решений Microsoft". Т.е. где-то сваять программку на C#, где-то сделать add-on для Dynamics AX/CRM/..., MS Office - в общем - всем понемножку. Опять-таки - партнеры не будут узконаправленными, а будут работать по всей линейке продуктов MS, что снова хорошо ложится в стратегию MS-а в целом
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: mazzy (2), Logger (3).
Старый 07.03.2016, 11:25   #46  
Link is offline
Link
Британский учённый
Аватар для Link
Соотечественники
 
568 / 513 (19) +++++++
Регистрация: 25.11.2005
Адрес: UK
Записей в блоге: 9
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код) и останутся dll-ки, к которым можно будет писать свои add-оны.
Т.е. внести изменение в стандартную форму n будет нельзя, но можно будет сделать свою очень похожую форму m с нужным функционалом. Тогда уже проще свою ЕРП писать с домино и куртизанками. Если следовать идее закрытия кода, разве код который хотели закрыть еще не закрыли, есть же много системного кода. А кастомный код и так можно писать только на верхних слоях. Так что логика не понятна.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще.
Старый 07.03.2016, 11:51   #47  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от trud Посмотреть сообщение
Ну как раз основная идея что для клиента это все будет намного проще
Т.е. представьте идею – вам нужно решение, например для склада. Вы заходите в каталог решений Azure, выбираете нужное решение(ну или вообще стандарт) и уже через несколько часов у вас разворачивается решение доступное по URL. Далее в LCS вы отмечаете нужные вам бизнес-процессы, сразу получается список шаблонов для начальных данных, которые нужно заполнить и загрузить в систему чтобы начать работать.
Давайте разберем по пунктам:
  • Для склада такое, может, и прокатит - там бизнес-процессов меньше пары десятков. Это если тупо склад, а не какой-нить 3PL-оператор.
  • "Тупо склад" с 15-ю бизнес-процессами - это ведь отнюдь не уровень среднего и крупного бизнеса, куда метит Dynamics AX, потому что там уже бизнес-процессов - под сотню, а то и более. Все их настроить и связать между собой с помощью шаблонов начальных данных? Что-то сомнительно.
  • Настроить ERP-систему пригоршней галочек - это, по-моему, утопия. Помнится, у локализаторов была такая затея - сделать некий мастер, который на основе демо-базы как набора шаблонов и каких-то галочек вроде как перельет в пустую базу нужное подмножество настроек, и получится готовая к употреблению система. Однако, идея в итоге заглохла: думается, с разрастанием функционала комбинаторная сложность такой задачи свела на нет все попытки ее автоматизации.
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Я так понимаю - процесс движется к идее, заложенной в MS Dynamics CRM, MS Office, MS Windows.
По-моему, в перечисленных системах заложены 3 совершенно разные идеи
  • MS Windows - это платформа для запуска приложений, которая, во-первых, сама по себе нафиг никому не нужна, во-вторых, она в целом ряде сценариев избыточна, требуя слишком много ресурсов и внимания для обслуживания самой себя (в т.ч. пресловутого накатывания заплаток и связанных с этим перезагрузок). Последние затеи типа Nano Server доказывают, что там не то что дописывать - в пору выкидывать лишнее.
  • MS Office - чудесный пакет, который установлен, наверно, практически у всех, но он реализует сравнительно небольшое число совершенно типовых сценариев использования, стабильных и неизменных на протяжении десятилетий и, кроме прочего, не зависящих от местного законодательства или иных особенностей. Максимум, где-то пишут слева направо, а где-то - справа налево. Как по мне, развитие функционала Ms Office остановилось на версии 2010, дальше пошли рюшечки и портирование на другие платформы.
  • А вот Dynamics CRM - отдельная тема...
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код) и останутся dll-ки, к которым можно будет писать свои add-оны. Ведь по большому счету никто же не посягает на исходные коды Excel, Word - все ими пользуются и пишут в отдельных случаях макросы (=add-оны).
Контр-пример: Dynamics Enterprise POS поставляется с частично закрытым кодом, и это приносит огромное количество проблем на проектах внедрения, при этом в Modern POS уже открыто все. А мотивы максимально не трогать штатный код могут быть иными: каждый, кто ставил обновления для стандартного приложения Аксапты, видел, как ради копеечного исправления в обновление по зависимостям тянутся тонны других изменений. Накатывать такие исправления неудобно, небезопасно, трудоемко, но логика тут тоже есть: раз имеется зависимость, то изменение одного из компонент "по умолчанию" влияет на все связанные, поэтому изменения должны поставляться общим большим пакетом. Так что и кастомизации, меняющие что-то в штатном коде, должны по зависимостям включать в себя тонны связанного кода. Отсюда - мораль: надо уменьшить число зависимостей и по возможности запретить напрямую менять штатный код, чтобы кастомизации было удобнее, безопаснее и менее трудоемко накатывать.
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Единственное, в чем пока остается неясность - так это в популяризации Dynamics. Конкуренция все-таки так или иначе на рынке ERP-систем присутствует и с российским менталитетом "мегакалькулятор" может на российском рынке проигрывать либо неконкуретной любимой программе бухгалтера , либо какой-нибудь немецкой программе, в которую легче внести изменения
По-моему, движение в сторону настройки галочками и невозможности менять стандартное приложение (только лепить что-то сбоку) как раз приведет Dynamics AX в сторону того же SAP с его узкими специалистами по отдельным модулям и их бесчисленным настроечным галочкам. Какая уж там настройка через LCS, да еще и силами самих клиентов!
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Консалтинг здесь будет зарабатывать видимо "ассортиментом решений Microsoft". Т.е. где-то сваять программку на C#, где-то сделать add-on для Dynamics AX/CRM/..., MS Office - в общем - всем понемножку. Опять-таки - партнеры не будут узконаправленными, а будут работать по всей линейке продуктов MS, что снова хорошо ложится в стратегию MS-а в целом
По-моему, нормально зарабатывать, занимаясь всем понемножку, малореально, потому что если будет небольшое число "специалистов широкого профиля", то они глубоко не будут разбираются ни в чем и вынуждены будут конкурировать со "студентами-недоучками", а если будет толпа узких специалистов, то у них будет эпизодическая, очень неравномерная загрузка. Специалист либо должен быть загружен по 8 часов 5 дней в неделю, либо его услуги будут космически дороги, либо он будет прозябать и уйдет в другие технологии/отрасли. А кроме того, вендор вроде как смотрит на ситуацию иначе: вертикальная специализация, а не горизонтальная "всеядность" и затыкание щелей на стыках различных продуктов. В конце концов, клиентам не нужен "ассортимент решений Microsoft", им нужно решение их проблем в их конкретной отрасли за приемлемые деньги, а уж будет ли решение основано на одном монолитном продукте или целом стеке технологий и каких-то микросервисов - дело десятое.

Последний раз редактировалось gl00mie; 07.03.2016 в 12:49.
За это сообщение автора поблагодарили: Morpheus (5).
Старый 07.03.2016, 15:09   #48  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Настроить ERP-систему пригоршней галочек - это, по-моему, утопия. Помнится, у локализаторов была такая затея - сделать некий мастер, который на основе демо-базы как набора шаблонов и каких-то галочек вроде как перельет в пустую базу нужное подмножество настроек, и получится готовая к употреблению система. Однако, идея в итоге заглохла: думается, с разрастанием функционала комбинаторная сложность такой задачи свела на нет все попытки ее автоматизации.
Не у локализаторов, а у штаб-квартиры. Локализаторы всего-лишь локализовывали.
Проблема не в комбинаторике. А в том, что выявились дублирующиеся галочки. Выявились дебильные галочки, для которых надо задавать очень дебильные вопросы. Выявились противоречия в поведении "галочек". А главное, стало понятно, что для настройки надо задавать вопросы не по галочкам, а по сути бизнеса клиента. А для этого майкрософту надо знать кто их клиент. Ну, и попутно рефакторить существующее.

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

Последний раз редактировалось mazzy; 07.03.2016 в 15:14.
Старый 07.03.2016, 16:24   #49  
Alex_KD is offline
Alex_KD
Участник
AxAssist
MCBMSS
Соотечественники
 
522 / 362 (14) ++++++
Регистрация: 06.07.2006
Адрес: Melbourne, Down Under
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код)
Сейчас делаются все шаги к тому, чтобы апгрейд был максимально безболезненный.
О закрытии кода никто не говорит.

Смотрите на Customization: Overlayering and extensions
и на Model split
__________________
AxAssist 2012 - Productivity Tool for Dynamics AX 2012/2009/4.0/3.0
Старый 08.03.2016, 10:13   #50  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Для начала скажу, что я высказал гипотезу, которая вполне может быть и ошибочна. Собственно - цель высказывания гипотезы и было обсуждение - насколько она жизнеспособна. Я вполне могу и ошибаться. И был бы рад прийти к любому единому пониманию.
Цитата:
Сообщение от Link Посмотреть сообщение
Т.е. внести изменение в стандартную форму n будет нельзя, но можно будет сделать свою очень похожую форму m с нужным функционалом. Тогда уже проще свою ЕРП писать с домино и куртизанками. Если следовать идее закрытия кода, разве код который хотели закрыть еще не закрыли, есть же много системного кода. А кастомный код и так можно писать только на верхних слоях. Так что логика не понятна.
Не... все гораздо проще. Запрет доступа к исходному коду не означает запрет изменения формы. Давайте вспомним, как нам предлагается изменение таблицы в АХ 7 - исходную таблицу мы не трогаем, но создаем к ней расширение. Таблица одна, но она состоит из исходной таблицы и расширения. Т.е. если в АХ 8 (9, 10, ...) закрыть доступ к исходному коду, но оставить "наружный интерфейс" - то в общем-то ничего не изменится по сравнению с АХ 7. Все также мы будем создавать расширения.
Более того - недавно belugin в теме обсуждения того, что некоторые методы надо было бы сделать не protected / private, а public - писал, что нехорошо смешивать детали реализации с интерфейсом реализации. Из этого следует, что MS не поощряет изменение штатного кода, который в т.ч. скрыт в private-методах.
Цитата:
Сообщение от gl00mie Посмотреть сообщение
По-моему, в перечисленных системах заложены 3 совершенно разные идеи
  • MS Windows - это платформа для запуска приложений, которая, во-первых, сама по себе нафиг никому не нужна, во-вторых, она в целом ряде сценариев избыточна, требуя слишком много ресурсов и внимания для обслуживания самой себя (в т.ч. пресловутого накатывания заплаток и связанных с этим перезагрузок). Последние затеи типа Nano Server доказывают, что там не то что дописывать - в пору выкидывать лишнее.
  • MS Office - чудесный пакет, который установлен, наверно, практически у всех, но он реализует сравнительно небольшое число совершенно типовых сценариев использования, стабильных и неизменных на протяжении десятилетий и, кроме прочего, не зависящих от местного законодательства или иных особенностей. Максимум, где-то пишут слева направо, а где-то - справа налево. Как по мне, развитие функционала Ms Office остановилось на версии 2010, дальше пошли рюшечки и портирование на другие платформы.
  • А вот Dynamics CRM - отдельная тема...
Контр-пример: Dynamics Enterprise POS поставляется с частично закрытым кодом, и это приносит огромное количество проблем на проектах внедрения, при этом в Modern POS уже открыто все. А мотивы максимально не трогать штатный код могут быть иными: каждый, кто ставил обновления для стандартного приложения Аксапты, видел, как ради копеечного исправления в обновление по зависимостям тянутся тонны других изменений.
По поводу систем: Это смотря с какой стороны смотреть на идеи. Берем Windows и Linux. В Linux код относительно Windows открыт. Вопрос: Какую легче систему апгрейдить? Ответ: Windows, т.к. там просто надо заменить dll-ки, да в реестр внести изменения (я конечно утрирую, но в целом - заменить dll-ки проще, чем исходный код).
Берем Office. Ему условно нет альтернативы (выпускаемые аналогичные пакеты - также с закрытым кодом. Возможно о каком-нибудь Open Office я и не знаю, но если там код открыт - было бы интересно также сравнить). В результате - к Office есть 100500 расширений / надстроек / кирпичиков кода / идей, как его "разнообразить" в работе.
Dynamics CRM - это тоже система, к которой дописываются расширения.

Цитата:
Сообщение от Alex_KD Посмотреть сообщение
Сейчас делаются все шаги к тому, чтобы апгрейд был максимально безболезненный.
О закрытии кода никто не говорит.
"Сегодня делаются все шаги к тому, чтобы все платили реальные тарифы за ЖКХ, РЖД, ... Увеличиваются пособия, чтобы повышение тарифов было максимально безболезненно. О повышении цен в магазинах и разгоне инфляции никто не говорит"
А если серьезно - сейчас делаются все шаги, чтобы разработчикам можно было бы не править исходный код, а можно было бы обходиться расширениями.
И как только MS наберет статистику, что потребности в модификации исходного кода нет - достаточно представить только интефейсы реализации - будет большой соблазн со стороны MS превратить исходный код в dll-ки и поставлять только эти dll-ки. И в этом плане AX превратится в CRM или в Office. Это как необходимость отладки на рабочем приложении. "За последние 15 лет я не сталкивался с необходимостью отладки на рабочем приложении" (с) с конференции. Все говорят, что это моветон и т.д. Но ... не верю я, что никто хотя бы раз не сталкивался с необходимостью посидеть в отладчике на рабочем приложении.

Т.е. сегодня никто не говорит. Может и завтра никто не скажет. Но послезавтра могут и заикнуться. Это же сильно упрощает обновление
__________________
Возможно сделать все. Вопрос времени
Старый 08.03.2016, 18:34   #51  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
По поводу систем: Это смотря с какой стороны смотреть на идеи. Берем Windows и Linux. В Linux код относительно Windows открыт. Вопрос: Какую легче систему апгрейдить? Ответ: Windows, т.к. там просто надо заменить dll-ки, да в реестр внести изменения (я конечно утрирую, но в целом - заменить dll-ки проще, чем исходный код).
Неправильный ответ: тупой заменой dll-ек мы получим знаменитый виндовый DLL Hell. В Windows легче ставить заплатки за счет поддержки установки side-by-side (SxS), когда в системе одновременно присутствуют разные версии одних и тех же dll-ек (в т.ч. управляемых сборок), необходимые для разных приложений или сервисов. В такой системе, как Аксапта, очевидно, эта аналогия не работает, потому что одновременная работа нескольких версий расчета цен/скидок или разноски журналов никому не нужна - максимум может быть несколько версий презентационной логики.
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
сейчас делаются все шаги, чтобы разработчикам можно было бы не править исходный код, а можно было бы обходиться расширениями. И как только MS наберет статистику, что потребности в модификации исходного кода нет - достаточно представить только интефейсы реализации. Т.е. сегодня никто не говорит. Может и завтра никто не скажет. Но послезавтра могут и заикнуться. Это же сильно упрощает обновление
По-моему, ключ именно в этом - в рефакторинге стандартного приложения, разделения его на отдельные "микросервисы" с выделением четко очерченных интерфейсов и закрытой расширяемой реализацией, с выделением точек расширения для "пристегивания" модификаций, как было отчасти сделано в FormLetter и иже с ним. Если будут нормальные интерфейсы, то закрытую реализацию можно будет относительно свободно менять в обновлениях стандартного приложения либо "заменять" в своих модификациях.
Но мне лично кажется, что пройдут годы, прежде чем такой рефакторинг будет реализован - если вообще будет, потому что приоритеты у вендора и KPI у его сотрудников могут оказаться совершенно иными.
За это сообщение автора поблагодарили: sukhanchik (3).
Старый 08.03.2016, 20:55   #52  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Неправильный ответ: тупой заменой dll-ек мы получим знаменитый виндовый DLL Hell. В Windows легче ставить заплатки за счет поддержки установки side-by-side (SxS), когда в системе одновременно присутствуют разные версии одних и тех же dll-ек (в т.ч. управляемых сборок), необходимые для разных приложений или сервисов. В такой системе, как Аксапта, очевидно, эта аналогия не работает, потому что одновременная работа нескольких версий расчета цен/скидок или разноски журналов никому не нужна - максимум может быть несколько версий презентационной логики.
Ээээ... Я не раскрыл мысль о количестве dll-лек. DLL Hell возникает при большом количестве dll-лек разных версий. Я предполагал, что их будет очень мало - вплоть до одной единственной. В АХ 2012 ведь по сути так оно и есть. Какие бы обновления не выпускались - в конечном счете все равно требуется пересобрать итоговый CIL, т.е. итоговую dll-ку.

Допустим, выпустил MS систему RTM-версии, состоящий из одной мега-dll-ки. Затем решил переделать механизм Dimensions. Переделал - выпустил фикс системы - выпустил эту новую мега-dll-ку. Изменились интерфейсы реализации - партнеры поставили этот апдейт, подкрутили у себя свой код своих расширений в связи с этим; как-то решили проблему обновления данных (вот этот вопрос кстати пока еще слабо проработан. Если приложение без кастомизации - вопросов нет - контрольный список все делает. А если с кастомизацией, то по идее партнеры должны также расширять контрольный список уже своими скриптами - но ... кто это делает в реале?). В результате - все обновились на эту новую мега-dll-ку и все счастливы . Знание исходного кода dll-ки не потребовалось.

Конечно, если dll-лек несколько - то проблемой совместимости нужно озадачиваться. И тут нам приходит на помощь расширения (packages) в АХ 7, которые контролируют зависимость объектов. Т.е. какие-то совсем независимые конструкции можно выделить в отдельные dll-ки, но уж зависимые - никак нельзя.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Но мне лично кажется, что пройдут годы, прежде чем такой рефакторинг будет реализован - если вообще будет, потому что приоритеты у вендора и KPI у его сотрудников могут оказаться совершенно иными.
Ну человеческий фактор никто не отменял. Но ... кто до выхода 2012 еще мог подумать, что в АХ 7 клиента Windows выкинут "в топку" и все уйдет в Visual Studio (примеры можно еще попридумывать)? Т.е. тоже казалось - что пройдут годы и все такое... Поэтому - будет на то воля - процесс ускорят. Не будет воли - не ускорят .
Но развитие событий в ключе возможного закрытия исходного кода - я бы не исключал. Безусловно - с кучей оговорок.

В общем - поживем-увидим. Спасибо за интересное обсуждение.
__________________
Возможно сделать все. Вопрос времени
Старый 18.03.2016, 19:36   #53  
imir is offline
imir
Участник
 
159 / 161 (6) ++++++
Регистрация: 28.05.2010
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
MS Dynamics CRM
Ведь по большому счету никто же не посягает на исходные коды Excel,
Еще как посягают, просто через сташный геморой с "дизасемблированием" и пересборкой, по крайней мере в шарике так.
Старый 19.03.2016, 10:49   #54  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Не вижу принципиальной сложности первести на html клиент или разработку в visual studio.

А вот сделать полный рефакторинг кода, с умом подойти к выделению очерченных сервисов с понятными инструментами их кастомизации, да так, чтобы это потом взлетело на практике - в текущих реалиях считаю практически нереальным. Рад бы ошибиться и дело даже не в человеко-годах на это, а на принятие правильных управленческих решений на этот счет. Пока же все примеры рефакторинга показывают чисто технический программистиский подход, и я даже не про локализацию сейчас.
__________________
Ivanhoe as is..
Теги
ax7

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
DAX: Microsoft Dynamics AX 2012 R3 is now available! Blog bot DAX Blogs 1 02.05.2014 23:00
atinkerersnotebook: Walkthrough & Tutorial Summary Blog bot DAX Blogs 1 09.09.2013 09:11
dynamics-ax: Kees Hertogh: The Benefits of a Model Driven Layered Architecture Blog bot DAX Blogs 0 30.03.2011 01:14
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:17.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.