17.04.2015, 12:43 | #1 |
Участник
|
AX vs SQL Server
Всем привет! У меня вопрос жизни и смерти :-) Сейчас у меня на руках два предложения о работе. Одно касается разработки для Microsoft Dynamics AX 2012 R2/R3, другое состоит в разработке для Microsoft SQL Server (T-SQL, SSRS, SSAS) + C# + ASP.Net WebForms. Я занимался AX 3.0, 4.0, 2009, а в 2012 у меня нет опыта... В SQL Server уверенные знания. Что выбрать? Чем посоветуете заниматься на будущее?
|
|
17.04.2015, 15:33 | #2 |
MCT
|
Я бы не строил свои планы в Dynamics AX на российских проектах.
__________________
Axapta book for developer |
|
17.04.2015, 16:42 | #3 |
Участник
|
Почему?
|
|
17.04.2015, 17:32 | #4 |
Британский учённый
|
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
17.04.2015, 18:28 | #5 |
Участник
|
Посмотрите тему Перспективы AX 2012
|
|
18.04.2015, 09:10 | #6 |
Участник
|
gl00mie, спасибо, интересная тема. Правда она датирована 2011 годом, но там, кстати, говорится о 2014-2015 годах: посмотрим что будет. Какая сейчас ситуация? Хотя бы какая ситуация была в 2014 году до роста доллара?
|
|
18.04.2015, 13:27 | #7 |
NavAx
|
Цитата:
Сообщение от GEP442
Всем привет! У меня вопрос жизни и смерти :-) Сейчас у меня на руках два предложения о работе. Одно касается разработки для Microsoft Dynamics AX 2012 R2/R3, другое состоит в разработке для Microsoft SQL Server (T-SQL, SSRS, SSAS) + C# + ASP.Net WebForms. Я занимался AX 3.0, 4.0, 2009, а в 2012 у меня нет опыта... В SQL Server уверенные знания. Что выбрать? Чем посоветуете заниматься на будущее?
К примеру, обычно гораздо проще и надежнее написать кастомный Web Service на C#, который с AOS будет разговаривать, чем разбираться в AIF. При этом сможешь любые протоколы использовать, а не то, что подсунули. Интегрированный SSRS тоже причудлив. В чистом ты будешь много писать и сразу видеть в preview, и таким образом быстро набивать руку и осваивать возможности. А в 2012 ты будешь делать CIL компиляции, чистить кэши, рестартовать AOS и истово молиться чтобы твои изменения таки отобразились. Потом ждать пока этот отчет заполнит все кэши и таки покажет что-то. Т.е. тупо терять время будешь. P.S. А еще, если посмотришь в банковский модуль, печать чеков, сопоставления, и платежки (я про западные) то тебе будут потом сны страшные сниться несколько месяцев и руки буду зудеть схватиться за топор и отсечь эту опухоль. А потом раскаленным прутом повыжигать метастазы и написать как надо за пару месяцев.
__________________
Isn't it nice when things just work? Последний раз редактировалось macklakov; 18.04.2015 в 13:33. |
|
|
За это сообщение автора поблагодарили: mazzy (2), Morpheus (3). |
18.04.2015, 14:51 | #8 |
Участник
|
macklakov, звучит страшно :-( Неужели всё настолько печально? Спасибо за совет!
|
|
18.04.2015, 19:54 | #9 |
Участник
|
Наверное, оффтоп, но всё же спрошу: а NAV также сильно изменилась в новых версиях как и AX 2012?
|
|
19.04.2015, 12:25 | #10 |
NavAx
|
А кому легко? Платят ведь хорошо. Приходится терпеть.
__________________
Isn't it nice when things just work? |
|
19.04.2015, 14:19 | #11 |
Участник
|
|
|
20.04.2015, 11:59 | #12 |
Модератор
|
Цитата:
Потом, как бы ни не хотелось , но разбираться с AIF боюсь все же придется по мере того как на него будут переводить всевозможные экспорты и импорты типа банковских платежек и выписок По SSRS таки согласен, удовольствие ниже среднего, но без него никуда
__________________
-ТСЯ или -ТЬСЯ ? |
|
20.04.2015, 17:31 | #13 |
Участник
|
|
|
21.04.2015, 07:29 | #14 |
NavAx
|
Цитата:
Особенно с банковскими выписками и платежками. Задумка использовать XSLT преобразования красивая и грамотная, но реально пользоваться невозможно. Даже после усиленной доработки напильником раскидать проводки по нескольким юр. лицам невозможно. Ну и, как всегда, форматы не задукоментированны, поэтому написать преобразование из банковского в промежуточный формат крайне тяжело. Собственно написание тупого импорта банковского файла занимает в разы меньше времени и работает в разы надежнее. Из причуд: ttsabort не отрабатывает нормально. Очень ограниченный набор протоколов. Тот же модный restful json не опубликуешь и не употребишь. Если хочешь что-то более-менее защищенное, нужно пользовать IIS. А это в несколько раз повышает вероятность сбоев. Логгирование ненадежное очень. Изменение настроек происходит о-очень медленно и может поронять все остальные сервисы. Black box. Отчего падает и чего хочет для работы бывает очень сложно понять. Как и все прочее, очень плохо задокументирован. К примеру, упоминание о том, как передавать структуры данных есть лишь в одной книге. И оно очень поверхностное. Т.е. для всяких системных нужд AIF штука полезная, в силу универсальности. Но для кастомной интеграции гораздо быстрее и надежнее написать свое. P.S. Но самое главное, что за время, которое требуется чтобы разобраться как сделать элементарные вещи в AIF можно успеть наработать весьма серьезные навыки в веб сервисах, если писать их в приличном API. И после этого уже в AIF не так сложно будет разобраться, т.к. знаешь что искать. А вот начиная с AIF понять хоть что-то очень тяжело.
__________________
Isn't it nice when things just work? Последний раз редактировалось macklakov; 21.04.2015 в 08:24. |
|
|
За это сообщение автора поблагодарили: fed (3), gudzon (1). |
21.04.2015, 11:14 | #15 |
Участник
|
Цитата:
Сообщение от macklakov
Но самое главное, что за время, которое требуется чтобы разобраться как сделать элементарные вещи в AIF можно успеть наработать весьма серьезные навыки в веб сервисах, если писать их в приличном API. И после этого уже в AIF не так сложно будет разобраться, т.к. знаешь что искать. А вот начиная с AIF понять хоть что-то очень тяжело.
|
|
21.04.2015, 11:40 | #16 |
NavAx
|
Нет наоборот, пишешь сервис на C# и из него обращаешься аксе.
Если хочешь употребить чей-то, то AIF не нужен совсем.
__________________
Isn't it nice when things just work? |
|