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

[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

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

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

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