4 года Dynamics AX 2012

[fed]

Спустя 4 года могу от себя добавить, что среди нововведений DAX2012 только одно мне кажется безнадежным - Subledger/Distributions/Source document architecture. Все остальное либо уже довели, либо оно может быть доведено в обозримом будущем. (Конечно если весь пар в облака не уйдет). А вот эта милая фича - классический пример того как кривая в прикладном смысле постановка приводит к кривому коду. Если у тебя изначально кривые user stories, то никакие паттерны и никакие грамотные разработчики не помогут - противоречия в прикладной области неизбежно приводят к кривизне и заплаткам в коде.

[Vadik]

Цитата:

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

Спустя 4 года могу от себя добавить, что среди нововведений DAX2012 только одно мне кажется безнадежным - Subledger/Distributions/Source document architecture

А бюджетирование, которое наполовину в X++, наполовину на хранимых процедурах, ты наверное еще не отлаживал ?

[fed]

Цитата:

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

А бюджетирование, которое наполовину в X++, наполовину на хранимых процедурах, ты наверное еще не отлаживал ?

Мне просто повезло Но вообще как-то финансисты наши со стандартным бюджетированием справляются. Но 95% проблем в финансовом модуле кончаются тем что мы отправляем в Микрософт очередную ошибку в распределениях.

[Morpheus]

Цитата:

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

...что среди нововведений DAX2012 только одно мне кажется безнадежным - Subledger/Distributions/Source document architecture.

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП. Одни временные таблицы и куча запросов группирует затем перегруппировывает записи читая их из одних таблиц и записывая в другие. Читать такой код сложно, исправлять/расширять еще сложнее.

[macklakov]

Цитата:

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

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП.

Я бы скзал что основная часть нового системного кода в 2012 написана вчерашними web-программистами. Заслуженными ветеранами asp кодинга. Поэтому ощущается большое недоверие структурам данных, к x++ запросам, к временным таблицам. Из-за этого так часто попадаются таблицы которые используются как временные, являсь обычными, а это, в свою очередь, приводит к конфликтам и накоплению мусорных записей. Еще ощущается полное непонимание, зачем нужен сервер приложений. Поэтому механизм кэширования не развивается, застрял на уровне конца 90-х и больше тормозит систему, чем ускоряет работу.
В сущности, morphX и x++ у них явно путаются под ногами, раздражают, и они хотели бы все это переписать под "нормальную" архитектуру. Но избавиться пока не могут, т.к. открытость кода и простота модификации является тем конкурентным приемуществом, благодаря которому система все еще представлена на рынке, несмотря на всю недоделанность. Для сравнения, разработка через add-on's в "правильном" CRM на порядки сложнее и "общедоступные" C# программисты в CRM, на поверку, оказываются очень редки и дороги.

[fed]

Цитата:

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

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП. Одни временные таблицы и куча запросов группирует затем перегруппировывает записи читая их из одних таблиц и записывая в другие. Читать такой код сложно, исправлять/расширять еще сложнее.

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

[macklakov]

Цитата:

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

туда в индусском стиле с помощью кувалды и медитации

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

Цитата:

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

overengineered ООП

overengineered потому, что народ понятия не имел как работает сервер. Поэтому иерархия, вроде, навороченная, а по факту, логика скриптовая. На каждый чих запись в БД. Из-за этого много таблиц на которых локи возникают.

Цитата:

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

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

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

[fed]

Цитата:

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

overengineered потому, что народ понятия не имел как работает сервер. Поэтому иерархия, вроде, навороченная, а по факту, логика скриптовая. На каждый чих запись в БД. Из-за этого много таблиц на которых локи возникают.

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