Why is the approach taken to de-integrate everything in Ax?

[glibs]

Просто по тому, как сейчас происходит интеграция (с чем только можно, лишь бы только побольше интеграции, при этом убрать из системы то, что было), у меня складывается впечатление, что мало кто из принимающих решение знает/помнит и понимает целый ряд технологий, которые были заложены в систему основателями. К моему великому сожалению многие уникальные идеи не только не получили развития, но и были затоптаны во благо интеграции с продуктами MS.

[glibs]

Цитата:

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

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

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

С учетом описанной выше оговорки у меня еще сложилось впечатление, что в то время как многое в Аксапте рискует исчезнуть во имя нового общего там интерфейса... некоторые технологии успешно взял на вооружение 1С.

Впрочем, инсайдерской информацией я не обладаю. Посмотрим, что будет дальше.

Я слышал отзывы нескольких клиентов, перешедших с 3.0 на 5.0. Общее мнение было: "Бе". Ax32.exe утяжеляется. Требования к ресурсам растут. Много нового функционала пишется так, что на тонких каналах будет тормозить (сама манера формы рисовать имеется в виду).

[gl00mie]

По поводу интеграции - мне кажется, на эту тему более чем исчерпывающе выразились тут: Peter Villadsen and Gustavo Plancarte: X++ to MSIL

Цитата:

Люди часто повторяют: надо стоять на плечах гигантов, и, думаю, в вашей студии это звучало не раз, но я чувствую, что это именно то, что мы должны делать. Нам не следует самим нести все затраты, связанные с поддержкой и развитием всей инфраструктуры, когда есть такие отличные вещи, как .NET, и Visual Studio, и LINQ.

Просто изначально в ядре Аксапты было реализовано много такого, что является совершенно самостоятельными продуктами у того же Ms, и тут возникает вопрос: либо дублировать разработку одних и тех же вещей, явно проигрывая с точки зрения возможностей в случае "изобретения велосипедов" для Аксапты, либо заменить встроенные в нее "велосипеды" интеграцией с самостоятельными продуктами, службами, технологиями. Среди таких "велосипедов" можно отметить:

• собственный протокол AOCP, заменный на RPC;
• собственный механизм аутентификации пользователей и шифрования их паролей, заменный на Windows-аутентификацию;
• собственный механизм управления всеми настроенными на машине AOS'ами (к слову, дырявый с точки зрения безопасности), замененный на стандартные виндовые сервисы;
• собственный формат БД для хранения приложения, замененный в 6-й версии на БД Ms SQL Server;
• собственный движок справки, замененный на HtmlHelp;
• собственный "движок" для корпоративного портала, замененный на Sharepoint;
• собственная среда разработки, часть функций которой плавно переходит в Visual Studio;
• собственный интерпретатор собственного же байт-кода, которые экспериментально заменяется на IL и CLR;
• собственный движок отчетов, местами противоречивый с точки зрения архитектуры и в прошлом явно неоднократно приспосабливаемый под какие-то частные задачи, а теперь постепенно уступающий место SSRS

В общем, когда разработку ведет сторонняя контора, не контролирующая платформу и технологии, которые используются ее продуктом, то логично сделать продукт в значительной степени самодостаточным, но когда разработку начинает вести компания, которая разрабатывает и платформу, и СУБД, и все сопутствующие технологии, то логично не дублировать все эти возможности в отдельно взятом продукте, а интегрировать его с тем, что уже есть и работает.
А по поводу утяжеления клиента и повышения требований к каналам... можно вспомнить того же Джоэла Спольски:

Цитата:

Разработчики, которые прикладывают много усилий в оптимизацию и делают компактные и быстрые программы, однажды проснутся и обнаружат, что усилия были потрачены зря в большей или меньшей степени. Или, в крайнем случае, можно сказать, что «это не дало конкурентного преимущества в долгосрочной перспективе», если вы человек, разговаривающий как экономист.
Разработчики, которые наплевали на производительность и ринулись добавлять классные функции в свои программы, получат в долгосрочной перспективе лучшие программы.

[fed]

Вспоминается старый анекдот про то как Хрущев съездил в Англию и по итогам визита решил перевести СССР на левостороннее движение. Ну и для начала, в качестве эксперимента, попробовали запустить 100 автомобилей на Садовое Кольцо по левой стороне.

Просто не очень понятно - какой смысл ЧАСТЬ среды разработки мигрировать на Visual Studio и вообще микрософтовские технологии, если в принципе не понятно как на VS и .net отмигрировать такую фундаментальную технологию как технология слоев.
Вот если уважаемые любители стоять на плечах гигантов объяснят мне как они собираются ее мигрировать - я перестану бухтеть.
Какой вот смысл делать все эти AOD-browser для Visual Studio, переносить отчеты на SSRS и выносить отчеты на WF (от которого даже знакомые .netовцы стонут и ругаются неприлично), если не видно способа миграции всего приложения и всей среды на новые технологии ?

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

[belugin]

Цитата:

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

Просто не очень понятно - какой смысл ЧАСТЬ среды разработки мигрировать на Visual Studio и вообще микрософтовские технологии, если в принципе не понятно как на VS и .net отмигрировать такую фундаментальную технологию как технология слоев.

Ну лично я предпочту немножко попереключаться между окнами, чем рисовать отчет в глюковатом MorphXном редакторе.

Цитата:

Вот если уважаемые любители стоять на плечах гигантов объяснят мне как они собираются ее мигрировать - я перестану бухтеть.
Какой вот смысл делать все эти AOD-browser для Visual Studio, переносить отчеты на SSRS и выносить отчеты на WF (от которого даже знакомые .netовцы стонут и ругаются неприлично), если не видно способа миграции всего приложения и всей среды на новые технологии ?

Возможно, тем кто делает видно, а не тебе. И тем, кто участвует в TAP.

Цитата:

Кстати - меня вот как-то мало волнует экономия разработчиков на разработке ядра, если это не сопровождается падением стоимости одной лицензии.

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

Цитата:

больше тратить денег на дополнительные работы на внедрении, связанные с той самой интеграцией ?

Пример, пожалуйста.

[fed]

Цитата:

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

Возможно, тем кто делает видно, а не тебе. И тем, кто участвует в TAP.

Дык возникает вопрос - если они технологию слоев в VS и .net поддержали, то почему они об этом не пишут во всех блогах и Channel 9, а пишут про какие-то примочки к AOD и улучшения в компиляторе X++ ?

Цитата:

ты думаешь лиуензии продаются по себестоимости?

А какая мне разница - насколько сильно сэкономил вендор ? Вот если конечная цена для меня ТОЖЕ упала - вот тогда я готов радоваться что вендор сэкономил на разработке отдельного сборщика мусора или редактора отчетов.
Вообще - забавно. В классической экономической теории, после того как товар выходит из нишевого рынка на массовый, его цена должна СИЛЬНО упасть, поскольку падает доля затрат на R&D в единице товара. (Вспомни цены LCD-мониторов 10 лет назад и сейчас). Однако, в случае Аксапты, эта цена почему-то выросла в ДВА раза.Как раз недавно знакомые, которые на старой схеме лицензирования остались, считали во сколько им лицензия на одного пользователя в 2001 году обошлась и сколько она же стоит теперь.

Цитата:

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

Меньше глюков ? Я две недели назад как с одного проекта. Дык вот там программисты из лучших побуждений сделали так, чтобы закупку нельзя было разнести пока она не пройдет большую цепочку утверждений. Однако выяснилось, что из за уникальной глючности ядра workflow в Аксапте, этот самый workflow не может пройти быстрее чем за 4-5 часов. После почти месяца общения с саппортом, удалось решить эту проблему, только закомментировав большую часть проверок security и прав доступа в workflow. Похоже что разработчики не тестировали свой код при числе пользователей больше 50 и числе групп больше 1.

Цитата:

Пример, пожалуйста.

Вот тут mazzy жалуется на то что ему приходиться держать одного человека на X++ и одного на Visual Studio axtools: Navigating the AX Application Explorer in Visual Studio
Не думаю что ему человек на C# обошелся бесплатно
Ну и тут еще glibs чуть выше написал.

[belugin]

Цитата:

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

Дык возникает вопрос - если они технологию слоев в VS и .net поддержали, то почему они об этом не пишут во всех блогах и Channel 9, а пишут про какие-то примочки к AOD и улучшения в компиляторе X++ ?

...в ценах не разбираюсь...

Цитата:

Меньше глюков ? Я две недели назад как с одного проекта. Дык вот там программисты из лучших побуждений сделали так, чтобы закупку нельзя было разнести пока она не пройдет большую цепочку утверждений. Однако выяснилось, что из за уникальной глючности ядра workflow в Аксапте, этот самый workflow не может пройти быстрее чем за 4-5 часов. После почти месяца общения с саппортом, удалось решить эту проблему, только закомментировав большую часть проверок security и прав доступа в workflow. Похоже что разработчики не тестировали свой код при числе пользователей больше 50 и числе групп больше 1.

Обрати внимание, что в предыдущей версии такой возможности вообще не было. Интересно, что Mazzy отвечает на форуме на вопросы про WF, причем, его ответы отличаются от фразы "не используйте WF"

Цитата:

Вот тут mazzy жалуется на то что ему приходиться держать одного человека на X++ и одного на Visual Studio axtools: Navigating the AX Application Explorer in Visual Studio
Не думаю что ему человек на C# обошелся бесплатно
Ну и тут еще glibs чуть выше написал.

про EP я не знаю. Насчет того, зачем mazzy человек на C# хотелось бы услышать подробнее.

[mazzy]

Цитата:

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

А самые современные технологии сами по себе результат не обеспечивают. И большинству пользователей фиолетово какими технологиями результат достигается.

Я хотел бы напомнить о Project Green.
Хотя его теперь так не называют, но развитие идет в полном соответствии этим планом (разве что только сроки постоянно сдвигаются)

http://forum.mazzy.ru/index.php?showtopic=2508
хочу напомнить, что в рамках первой волны Майкрософт сделал более-менее одинаковый функционал. Не знаю как GP и SL, а вот объяснить обычному пользователю разницу между NAV и AX теперь стало практически невозможно (технологическая разница есть).

в рамках второй волны Майкрософт собрался перевести функционально одинаковые продукты на единую технологию. Что сейчас и происходит.

Опять же... У Navision переход осуществляется более плавно, бесшовно и более безболезненно, чем у Аксапты (хотя и там матричные формы потеряли... но зато нашли массу других вещей)
В частности В NAV 2009 код C/AL конвертится в C#, а что же будет в DAX?
и alexef: Navision - технический взгляд (NAV2009, SP1, ...)

Цитата:

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

Интересно, что Mazzy отвечает на форуме на вопросы про WF, причем, его ответы отличаются от фразы "не используйте WF"

1. Давайте оставим Mazzy в покое.
1.1. Его мнение может быть ошибочным.
1.2. Не думаю, что мнение является аргументом
2. кроме того, я не говорю "не используйте WF" потому что пока надеюсь на следующие версии и выражаюсь вежливо.

Цитата:

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

Насчет того, зачем mazzy человек на C# хотелось бы услышать подробнее.

Отчеты писать на VS. Сервисы для оборудования (например, терминалы сбора данных). Портал программировать.

в общем, все то что Майкрософт перевел на .net

я согласен с fed, что перспективы недостаточно ясно доведены до сознания людей.
ссыла на TAP-программу не катит. Потому что TAP-программа находится под тем же соглашением о неразглашении NDA. А такая базовая информация должна быть доступной для широкого круга пользователей и потенциальных пользователей (лично мне без разницы, что десяток участников TAP-программы в чем-то убедились. но лично мне будет плохо, если сотни потенциальных пользователей отвернутся от Аксапты в виду отсутствия внятной информации)

Цитата:

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

Ну лично я предпочту немножко попереключаться между окнами, чем рисовать отчет в глюковатом MorphXном редакторе.

Возможно. Я тоже не против попереключаться.
Но как я уже писал меня просто выворачивает от того, что VS не знает кучу вещей, привычных для разработчика на X++. Прежде всего не знает о EDT, enum и relations.

[mifi]

Цитата:

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

Я две недели назад как с одного проекта. Дык вот там программисты из лучших побуждений сделали так, чтобы закупку нельзя было разнести пока она не пройдет большую цепочку утверждений.

Так это программисты сделали, без запроса от руководства проекта внедрить цепочку утверждений? Они, видимо, по ночам работали и потом тайком перенесли на рабочую версию?
Или это все-таки было бизнес-требование от ЛПР. Если это было бизнес-требование, то насколько проще, дешевле и безглюкавее это было бы сделать без встроенного workflow в AX?
Возвращаясь к дискуссии про SSRS. Ничего, кроме отвращения не могу вспомнить о собственном dev experience создания более-менее сложных отчетов в MorphX.
Этот движок хорош только для создания автоотчетов
Если считать за аксиому, что среда разработки ERP-системы должна позволять создавать сложные отчеты, включая графику, то тут есть два пути развития:
1. Изобрести велосипед, т.е. разработать новый движок внутри MorphX
2. Сделать хорошую интеграцию с уже имеющимся движком того же вендора, реализовав возможность создавать автоотчеты и обращаться к метаданным AX
В AX6 сейчас активно ведутся работы по направлению 2. Что в этом плохого - непонятно. Да, старым аксаптоведам (вроде меня) придется немного подучиться. И все.

[mazzy]

Цитата:

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

Возвращаясь к дискуссии про SSRS. Ничего, кроме отвращения не могу вспомнить о собственном dev experience создания более-менее сложных отчетов в MorphX.

Вы наверное рисовали эти безумные формы с рамочками как в Счете, счете-фактуре и т.п.?
Для рисования таких "красивых" объектов MorphX подходит плохо.

Вот если бы у постановщиков задач в Майкрософте зватило духу поставить задачу не так "сделать как в 1С", а так "сделать как стандартные в Аксапте", то и ваше мнение было бы другим, и мнение клиентов, и мнение многих программистов, которые работают с этими угребищными отчетами с рамочками.

А нужно то было всего лишь, отказаться от рамочек в отчетах... Впрочем, про рамочки и способах создания отчетов без них писалось на форуме неоднократно.

Цитата:

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

Этот движок хорош только для создания автоотчетов

Именно!!!!
Причем пользователи могут сами выворачивать запросы и получать итоги по любым группировкам. Только для этого программисту не нужно вмешиваться своими лапками в запросы, не нужно фиксировать порядок таблиц, сортировок и полей, не нужно скрывать условия от пользователей.

Нужны итоги по строкам заказа? нет проблем - делайте автоотчет.
Нужны итоги по строкам журнала? нет проблем - делайте автоотчет.
Нужны итоги по складским движениям? нет проблем...

Цитата:

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

Если считать за аксиому, что среда разработки ERP-системы должна позволять создавать сложные отчеты

Э-э-э... А зачем принимать такую аксиому?

Мне кажется, что аксиомы должны быть другими:
1. ERP-система должна позволять пользователю быстро и лего получить нужные ему данные из одной или двух-трех таблиц.
2. ERP-система должна позволять программисту быстро и легко сделать сложные связи и получить данные из нескольких таблиц
3. ВАЖНО! полученные данные ERP-система должна уметь выгружать в Excel.

Все! Большего от ERP-системы и не нужно по большому счету.
Если пользователям нужна графика, то переносим в Excel и применяем диаграммы/графики

Беда morphX отчетов в том, что там нет инструмента для выгрузки данных в Excel.

Цитата:

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

2. Сделать хорошую интеграцию с уже имеющимся движком того же вендора, реализовав возможность создавать автоотчеты и обращаться к метаданным AX

Я - за хорошую интеграцию.
Я против интеграции-только-для-того-чтобы-интеграция-была.

[fed]

Цитата:

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

Так это программисты сделали, без запроса от руководства проекта внедрить цепочку утверждений? Они, видимо, по ночам работали и потом тайком перенесли на рабочую версию?
Или это все-таки было бизнес-требование от ЛПР. Если это было бизнес-требование, то насколько проще, дешевле и безглюкавее это было бы сделать без встроенного workflow в AX?

Workflow сделали естественно по просьбам ЛПР. Счас клиент понимает что сделать без встроенного workflow было бы проще дешевле и безглюкавее.
Но это понимание пришло только после того как клиент сначала показал workflow пользователям, потом (после того как выяснилось что встроенный workflow мало что может) потратил кучу средств на изучение способов доработки workflow в .net, а потом при старте системы выяснилось что при реальном количестве пользователей, групп и прав, функция securityKeySet.loadUserRights() может отработать за 0.2 секунды, а может и за 45. Соответственно - стандартное ядро WorkFlow и системы обработки Eventов постоянно ждало завершения этой функции и события в очереди стояли по 5-6 часов.

Цитата:

Возвращаясь к дискуссии про SSRS. Ничего, кроме отвращения не могу вспомнить о собственном dev experience создания более-менее сложных отчетов в MorphX.
Этот движок хорош только для создания автоотчетов
Если считать за аксиому, что среда разработки ERP-системы должна позволять создавать сложные отчеты, включая графику, то тут есть два пути развития:
1. Изобрести велосипед, т.е. разработать новый движок внутри MorphX
2. Сделать хорошую интеграцию с уже имеющимся движком того же вендора, реализовав возможность создавать автоотчеты и обращаться к метаданным AX
В AX6 сейчас активно ведутся работы по направлению 2. Что в этом плохого - непонятно. Да, старым аксаптоведам (вроде меня) придется немного подучиться. И все.

Просто отчеты на SSRS выпустили еще в версии 4.0. Похоже что до более или менее работоспособного состояния их доведут в версии 6.0
Именно это-то и пугает. Вот сделают счас компиляцию в .net на лету. Дык страшно подумать что будет, если первые пару версий это будет работать так же стабильно как SSRS или WF в версиях 4.0 и 2009. И если проблемы с отчетами или WF еще можно как-то обойти, то проблемы с ядром системы исполнения - явно нет...

[EVGL]

Цитата:

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

Меньше глюков ? Я две недели назад как с одного проекта. Дык вот там программисты из лучших побуждений сделали так, чтобы закупку нельзя было разнести пока она не пройдет большую цепочку утверждений. Однако выяснилось, что из за уникальной глючности ядра workflow в Аксапте, этот самый workflow не может пройти быстрее чем за 4-5 часов. После почти месяца общения с саппортом, удалось решить эту проблему, только закомментировав большую часть проверок security и прав доступа в workflow. Похоже что разработчики не тестировали свой код при числе пользователей больше 50 и числе групп больше 1.

Да, workflow - это фантастическая история успеха. Я, кажется, уже рассказывал, что наш "отдел новых технологий" пару лет назад получил заказ оценить WF, сравнив ее с примитивной разработкой нашей компании (да чего уж там, с моей примитивной разработкой). Вердикт был однозначен: руки прочь от того, что сделано в AX, оставаться на том, что сделал Глазов.

У примитивной разработки Глазова образца 2004 года было одно и решающее преимущество: ничего не надо было программировать и не надо было подключать никаких сторонних систем.

Мне кажется, WF постигла судьба фичей, отданных на откуп программистам без конкретного технического задания. Т.е. фиче было суждено была делать не то, что нужно, а то, что можно. Такая же судьба постигла Commerce Gateway: после 4 лет и полной переработки получили более-мене удобоваримый продукт под названием AIF.

[belugin]

Цитата:

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

выносить отчеты на WF (от которого даже знакомые .netовцы стонут и ругаются неприлично),

Кстати, спроси их, что они думают про WF 4

[fed]

Цитата:

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

Кстати, спроси их, что они думают про WF 4

Дык может не надо было Аксаптовский workflow релизить ДО выхода WF4 ?
Вот внедрили бы лучше Аксапту внутри MBD и тренировались бы на кошках

[gl00mie]

Цитата:

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

в принципе не понятно как на VS и .net отмигрировать такую фундаментальную технологию как технология слоев.

А что сейчас мешает реализовать технологию слоев на .NET? В принципе, что она из себя представляет?
Для начала определимся с терминологией. Объект приложения - уникальная сущность, характеризующаяся рядом обязательных атрибутов: тип, имя, идентификатор объекта, идентификатор родительского объекта. Слой является объединением различных объектов приложения и единицей его развертывания. При этом на одном слое могут находиться лишь объекты приложения, которые в рамках слоя уникально идентифицируются комбинациями значений атрибутов [тип, идентификатор родительского объекта, идентификатор объекта] и [тип, идентификатор родительского объекта, имя] (см. AX models - Part 3 - Multiple models per layer). Объекты с одинаковыми комбинациями значений этих атрибутов могут находиться на разных слоях. Объект приложения верхнего уровня - такой объект, который не относится к другому, родительскому объекту (идентификатор родительского объекта у него пустой), но сам может быть родительским для других объектов, причем эти дочерние объекты могут находиться на разных слоях. Все типы объектов приложения четко разделены на типы, объекты которых являются объектами верхнего уровня, и типы, объекты которых являются дочерними по отношению к другим объектам, более того, для каждого типа объектов верхнего уровня есть четко определенное подмножество возможных типов дочерних объектов. Мощностью такого подмножества типов определяется гранулярность, с которой можно модифицировать объекты верхнего уровня; собственно, на данный момент такая гранулярность характерна для объектов бизнес-логики, но не презентационной логики.
С учетом взаимосвязей между различными типами объектов приложения, определяющих гранулярность модифицируемости объектов, и их распределения по слоям, можно из нескольких слоев с учетом их очередности ("приоритетов") собрать объекты приложения верхнего уровня (таблицы, классы, формы, отчеты, etc). На слоях более высокого уровня можно как создавать новые объекты приложения (в т.ч. дочерние по отношению к другим объектам - новые поля таблиц или методы классов), так и создавать копии объектов приложения из нижележащих слоев и модифицировать эти копии - в результате при сборке объектов приложения верхнего уровня будут использованы новые или модифицированные объекты-"гранулы" из слоев более высокого уровня. После сборки объекта верхнего уровня в памяти создается его некое представление, как в CLR создается экземпляр объекта-типа (класса), на который ссылаются все создаваемые экземпляры соответствующего класса (хотя применительно к Аксапте это лишь моя теортия, но я несколько раз был свидетелем того, как "представление" одного класса на клиенте и сервере "разъезжалось"). Сейчас все это делается на базе БД собственного формата, с 6-й версии приложение перенесут в БД Ms SQL Server, суть от этого не меняется.
Так вот, что мешает после получения из нескольких слоев целостного представления объекта "верхнего уровня" создать на лету соотв. .NET-сборку и использовать ее для создания экземпляров того или иного класса (в широком смысле)? Насколько я понимаю, схожим образом уже работает NAV 2009:

Цитата:

Что такое Service Tier?
Очень кратко - это промежуточный уровень в Microsoft Dynamics NAV 2009. Именно на этом уровне [теперь?] выполняется весь доступ к БД и вся бизнес-логика, что также означает, что именно на этом уровне выполняется код приложения.
...
А этот Service Tier занимается интерпретацией кода C/AL?
Как вы, вероятно, уже знаете, ответ на этот вопрос - нет. В NAV 2009 большая часть этого самого Service Tier написана на C# и выполняется в виде управляемого кода, кроме того, приложение тоже конвертируется в C# и во время работы также выполняется в виде скомпилированного управляемого кода.
Это происходит за счет того, что каждый раз, когда вы компилируете объект в C/SIDE, этот объект "за кулисами" транслируется в C#, и этот исходный код C# сохраняется в таблице Object Metadata в BLOB-поле с названием User Code. Кроме того, в таблице Object Tracking обновляется поле Object Timestamp, что позволяет Service Tier'у увидеть и подхватить эти изменения. Когда ему нужно выполнить код объекта, соответствующий объекту исходный код C# записывается на диск и посредством неких манипуляций компилируется в модуль, который может быть загружен динамически, что позволяет Service Tier на лету заменять отдельные code unit'ы, страницы, etc.

Цитата:

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

Однако, как все мы знаем, стоимость лицензии с каждым годом только растет...

По-моему, с учетом перехода на новую схему лицензирования сложно однозначно утверждать об этом. Стоимость лицензии на одновременно работающих пользователей, позволяющая использовть Windows-клиента, растет, однако, для существенной доли пользователей может подойти DCO-лицензия, которая на порядок дешевле. С учетом того, что корпоративный портал покрывает весьма ощутимую долю стандартного функционала, часть пользователей, которым не нужен полноценный Windows-клиент, а достаточно доступа через портал или стороннее приложение, использующее business connector, можно перевести на DCO-лицензии и за счет этого существенно сэкономить на стоимости лицензий.

Цитата:

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

Вроде писали, что не заменили, а завернули одно внутрь другого.

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

Цитата:

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

Кто пытался завести десятки и сотни тысяч пользователей на портале через AD очень в восторге от этой идеи.

С задачами массового заведения пользователей в Аксапте (чтоб прям тысячами), врать не буду, я не сталкивался, но когда аналогичная задача решается при администрировании виндовых доменов, то делается это отнюдь не руками.

Цитата:

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

А чем это лучше если не секрет? В VS тоже исходный код в реляционной СУБД живет?

Хранение приложения в БД лучше хотя бы тем, что приложение до 6-й версии оставалось единственным узлом системы, для которого отказоустойчивость можно обеспечить в весьма ограниченном масштабе - дисков в RAID побольше поставить, UPS для сервера понадежней, да и, в общем-то, все. Вплоть до AX 2009 включительно для приложения не поддерживается ни кластеризация, ни DFS, в результате если отвалится один из серверов с AOS'ами или один из узлов кластера СУБД, то работа большинства пользователей от этого не остановится, а вот если отвалится файл-сервер с приложением, то встанет всё (конечно, можно держать несколько копий приложения на разных серверах, но официально это не поддерживается). Реляционная СУБД на этом фоне предоставляет куда более широкие возможности по обеспечению отказоустойчивости, при этом еще и обеспечивая куда более высокую скорость и гибкость работы с метаданными:

Цитата:

Today the speed is back. Navigating the AOT is suddently a pleasure again. Meta data heavy operations, like searching, completes an order of magnitude faster. For example; searching all methods on forms for any text completes in 2 seconds.

Цитата:

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

А старый движок был проще. И это было единое хранилище, а не кучка файлов. И слои были, кажется. И вызов пунктов меню.

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

Цитата:

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

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

Всё так, но большинство пользователей просто не представляют, что их определенные каждодневные задачи можно решать как-то по-другому. Например, пользователи 1С "не знают" о dynalink, а пользователи 3-ей Аксапты "не знают" о тех же оповещениях или об Office Snap-ins...

Цитата:

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

Дык может не надо было Аксаптовский workflow релизить ДО выхода WF4 ?
Вот внедрили бы лучше Аксапту внутри MBD и тренировались бы на кошках

Не знаю, кто такой MDB, но Аксапта, к примеру, внедрена в Microsoft Home and Entertainment Division (HED), занимающемся разработкой Xbox, и - по официальным данным - вполне себе успешно там используется.

[mazzy]

Цитата:

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

А что сейчас мешает реализовать технологию слоев на .NET? В принципе, что она из себя представляет?
...
Так вот, что мешает после получения из нескольких слоев целостного представления объекта "верхнего уровня" создать на лету соотв. .NET-сборку и использовать ее для создания экземпляров того или иного класса (в широком смысле)? Насколько я понимаю, схожим образом уже работает NAV 2009

Да. Согласен.

Но речь идет скорее не о реализации и технологии, а о поддержке технологии средой разработки.
Сравнение слоев, фиксированный интерфейс методов из нижележащих слоев (тип возвращаемого результата, список переменных с типами), автоматический подъем в новый слой при изменении объекта. и т.п.

сборками - это правильно. Но уж очень трудоемко по сравнению со слоями в Аксапте. Хотя согласен, что на порядки более гибко, чем слои в Аксапте.

[glibs]

Цитата:

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

...
собственный протокол AOCP, заменный на RPC;
...

Вроде писали, что не заменили, а завернули одно внутрь другого.

Цитата:

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

...
собственный механизм аутентификации пользователей и шифрования их паролей, заменный на Windows-аутентификацию;
...

Кто пытался завести десятки и сотни тысяч пользователей на портале через AD очень в восторге от этой идеи.

Цитата:

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

...
собственный формат БД для хранения приложения, замененный в 6-й версии на БД Ms SQL Server;
...

А чем это лучше если не секрет? В VS тоже исходный код в реляционной СУБД живет?

Цитата:

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

...
собственный движок справки, замененный на HtmlHelp;
...

И справки не стало. А старый движок был проще. И это было единое хранилище, а не кучка файлов. И слои были, кажется. И вызов пунктов меню.

Цитата:

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

...
собственный "движок" для корпоративного портала, замененный на Sharepoint;
...

Развертывание стало трудоемким. Польза в чем? Может производительность подросла, но не слышал примеров от практиков, к сожалению. Не факт, что это был единственный путь.

Цитата:

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

...
когда разработку ведет сторонняя контора
...

Да, Аксапта много потеряла когда попала в лапы Микрософту.

Цитата:

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

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

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