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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 22.03.2017, 01:34   #41  
Egil is offline
Egil
Участник
Сотрудники Microsoft Dynamics
 
2 / 39 (2) +++
Регистрация: 21.03.2017
Попробую и я вставить пять копеек в дискуссию со стороны NAV. Начну, пожалуй, с моего видения плюсов закрытого кода. Я как раз сторонник мнения, что открывать всё и сразу не стоит. Базовый код приложения лучше держать закрытым от изменений. Разумеется, при условии наличия эффективного инструментария для доработок другими методами.
Основной минус закрытого кода вполне очевиден - вследствие невозможности изменения кода приходится изыскивать сложные решения там, где в открытом коде проблема решается простейшей модификацией. Вместо того, чтобы открыть дизайнером объект, считающий скидку, и добавить один фильтр на таблицу, мы начинаем изобретать велосипед и дублировать логику.
Плюсы этого подхода, как водится, есть обратная сторона минусов, поскольку быстрые решения вида "сейчас две строчки тут подправлю, и всё заработает" имеют нехорошее свойство просто перекладывать проблему в другое место и другое время. И доводы ниже - это скорее ловушки модификации кода, от которых предостерегает запрет изменений.

1. Исправления багов в C/AL коде NAV выпускаются в виде ежемесячных кумулятивных апдейтов. Каждый апдейт - это просто текстовый файл со всеми объектами, изменёнными за прошедший месяц. Если в соответствующих объектах в вашей базе нет кастомизаций - нет и проблем с накатыванием апдейта. Объекты импортируются, компилируются, и работа продолжается. При этом даже минимальные изменения в пользовательской базе требуют ручной работы. А объект, переписанный до неузнаваемости, превращает рутинную механическую задачу в новую разработку с сопутствующим тестированием. В результате с высокой
вероятностью хотфиксы в кастомизированные объекты будут импортироваться в лучшем случае выборочно, исключительно для сценариев, непосредственно затрагивающих бизнес-процессы клиента - по принципу "когда жареный петух клюнет".

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

3. Ну и наконец, не стоит забывать, что продукты Dynamics движутся семимильными шагами по дороге в облака. А SaaS и кастомизация вообще совмещаются крайне сложно и с громким скрипом. Если облачным сервисом пользуются десять клиентов, и каждый из них требует считать скидку по-своему, каждая из десяти модификаций потребует наличия отдельной базы. И все проблемы с интеграцией кода можно смело умножать на количество баз. Расширения (extension package), основанные на событиях, не встретятся с такими сложностями. В multitenant архитектуре расширение импортируется на нужный tenant - только для клиента, которому
оно необходимо. Базовый код приложения при этом остаётся без изменений, кастомизации работают на отдельных тенантах.

Если вернуться к вопросу о том, как же нам посчитать скидку во враждебных условиях закрытого кода, то решение уже было описано выше. Поскольку паттерн interceptor разработчикам NAV пока недоступен (да, быть богатым и здоровым, несомненно, лучше), то выход остаётся один - перехватывать инициативу после того, как базовый код приложения посчитал скидку, и заменять результат на свой. Кодюнит Sales-Calc. Discount для этого предоставляет событие OnAfterCalcSalesDiscount. Аналогичное событие OnAfterCalcPurchaseDiscount есть в Purch.-Calc.Discount.

К вопросу о том, как разработка поставлена в Европе / США vs СНГ. В европейских странах (Германия, Великобритания, к примеру) и Штатах NAV распространён гораздо больше, чем в России. Но там и смысл, вкладываемый в аббревиатуру SMB, несколько отличается от российского понимания этого термина. Гораздо больше компаний, которые покупают NAV действительно как коробочный продукт - без модификаций или с минимальными изменениями скорее косметического характера. У таких клиентов больших проблем с модификациями не возникает. Те же, кто покрупнее и могут себе позволить лицензию за много тысяч денег и штат разработчиков (как альтернатива - регулярно платить партнёру за доработки), зачастую попадают в ту же ловушку глубокой кастомизации - до сих пор работают на шестой версии и с грустью отгоняют печальные мысли о неизбежном апгрейде.
Именитые ISV (к примеру, Lanham, Cosmo Consult / Tectura) активно работают над переносом своих решений на модель extension package. Для монстров вроде LS Retail или Incadea такой переход, конечно, будет гораздо тяжелее, но, думаю, и они не отстанут.
За это сообщение автора поблагодарили: ax_mct (10), mazzy (5), sukhanchik (5), dn (5), Sancho (2).
Старый 22.03.2017, 02:55   #42  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от mazzy Посмотреть сообщение
Как правильно вести разработку в условиях, когда часть кода закрыта от изменения
Мне кажется, не с того конца к проблеме подходим. Система изначально спроектирована исходя из предположения что код открыт. Поэтому цеплять к ней extensions проблематично. Все слишком сильно переплетено и перепутано. Часть логики в классе, часть логики на форме, часть на таблице, часть вообще в макросах (не к ночи будут помянуты), часть в хранимках, часть в dll. И при этом четкого разграничения между модулями нет и интеграция дырявая. Тронешь проекты, надо заказы на продажу подкручивать. API задукоментирована сами знаете как и при этом довольно противоречива. Более того, традиционно локализации не поспевают. А для глобальных контор это большая проблема. Толку от американского функционала, если в новой каледонии новую систему налогообложения вводят?
Так вот, по правильному, конечно же, стоило бы переписать стандарт так, чтобы не было нужды ковыряться в мешанине. Четкое, хорошо задукоментированное API. И обновления по всему миру должны выходить с оперативностью 1С. Даже в регионах, которые с точки зрения объемов продаж, кажутся маловажными.
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: mazzy (2), ax_mct (10).
Старый 22.03.2017, 08:28   #43  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от macklakov Посмотреть сообщение
стоило бы переписать стандарт так, чтобы не было нужды ковыряться в мешанине. Четкое, хорошо задукоментированное API. И обновления по всему миру должны выходить с оперативностью 1С. Даже в регионах, которые с точки зрения объемов продаж, кажутся маловажными.
базаров нет - лучше быть богатым и здоровым.
мало того, я бы даже сформулировал "вендор должен переписать" )))


Цитата:
Сообщение от macklakov Посмотреть сообщение
Мне кажется, не с того конца к проблеме подходим.
я предлагаю сразу пропустить тривиальные шаги и сформулировать тему следующим образом:

Как вести разработку с минимальными в долгосрочной перспективе трудозатратами
в условиях, есть куча унаследованного кода И часть кода закрыта от изменения,
а платформа предоставляет систему событий и подписок?


Что должен внести в код вендор?
Какие техники и приемы может применять партнер/клиент?

=========================
пока прозвучали варианты:
= снять ограничения и писать поверх (лицензионным или нелицензионным способом)
= врезаться в существующие event'ы.
=== при этом ожидается что будет дублирование кода
=== один из крайних вариантов - полное дублирование - врезаться в событие "загрузка системы" и после этого не отдавать управление стандартному приложению

ограничения, насколько я понимаю:
= в закрытые объекты новые евенты добавить нельзя
= подписчик может не иметь доступа к паблишеру события, поэтому часть информации возможно придется передавать через глобальные переменные

доводы в пользу закрытого кода (см. жаркие холивары 90х и начала 2000х о закрытых/открытых системах):
= обновление на новую версию становится очень легким за счет усложнения первоначальной разработки и кастомизации

=========================
еще соображения?

какие ближайшие аналоги вы можете привести? другими словами, где можно посмотреть как действуют люди в подобных ситуациях?
я абсолютно не верю, что ситуация с dynamics является уникальной и ни на что не похожей. значит, кто-то и как-то уже решал подобные задачи.
будем применять тот опыт или не будем - можно решить после того, как посмотрим на аналоги.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 22.03.2017 в 08:42.
Старый 22.03.2017, 10:09   #44  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Внесу еще немного соображений на тему обновлений.
Я разделяю обновления на 2 типа:
1. Обновления в рамках текущей версии. Тут об этом уже много было сказано, поэтому опускаю этот пункт.
2. Переход на новую версию. Тут постараюсь раскрыть свои соображения

За все свое время знакомства с АХ с 2004 года - я постоянно слышу фразу, что что-то надо делать именно так, ибо это упростит / не усложнит процесс обновления. И что интересно - все разработчики / консультанты (в общем внедренцы) эту мантру постоянно повторяют. При том, что я ни разу не слышал эту мантру от директоров ИТ и представителей заказчика (за исключением ситуации, когда они это говорят со слов тех же внедренцев).
Т.е. когда покупают систему (я говорю на примере АХ) - никто даже в мыслях не рассуждает об обновлениях. Когда покупают MS Office / SQL Server / Visual Studio - то говорят - вот мы мол купили лицензию на 2010-й Office / 2010-ю студию и мы не можем ставить 2013-й офис или 2013-ю студию - т.к. на них нужна новая лицензия. Мы лучше поставим на новый комп то, что мы купили.

Ну т.е. бизнесу нужен инструмент, чтобы пользоваться. А не обновление ради обновления.
Многие из нас пользуются Word-ом на уровне какого-нибудь Word 2.0 / 97 и им этого хватает. Мы обновляемся только потому, что нас по сути заставляет это делать MS. Выпускаются новые компьютеры с новыми версиями ОС, которые плохо совместимы со старыми программами и мы вынуждены обновляться.

Как-то в свое время я общался с директором ИТ компании, в которой стояла AX 4.0, в то время как внедрения 2009-й уже активно "шагали по стране", а MS уже строил планы на AX 2012. Я спросил (естественно, с корыстными интересами) - а почему вы не хотите обновиться на 2009? И он ответил, что какой смысл обновлять только логотип системы, если мы не будем использовать все новые возможности новой версии? Т.е. зачем тратить деньги на то, что под флагом внедрения AX 2009 у нас будет стоять функционально та же AX 4.0? А если использовать все новые возможности - то это уже перевнедрение с реинжинирингом бизнес-процессов.

Общий смысл, который я хочу донести - не надо закладываться на какую-то эфемерную возможность обновления. Давайте посчитаем - сколько будет стоить обновление (работы по обновлению) и сколько будет стоить нам соблюдение некоторых правил, которые нам якобы упростят обновление. Будет ли стоить овчинка выделки?

Я не раз сталкивался с внедрениями, когда во внедренную АХ "завернута" по сути старая версия системы. И это понятно и это логично - внедренец тоже где-то должен постигать новую версию. Только вот бизнесу-то это не нужно.

И еще был пример. "Почему вы не хотите внедрить учет по МСФО?". "А зачем? Мне внедрение влетит в копеечку и затянется по срокам. Мне дешевле посадить девочку, которая за 2-4 недели вручную перелопатит все данные и построит отчет для аудиторов. А требуется мне это 1 раз в год".

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

Выводы из моего поста: Довод в пользу закрытого кода, как "упрощение обновления" - в рамках моих соображений - сомнителен. Естественно я рассуждаю с т.з. бизнеса. С т.з. вендора - само собой он упрощает работу самого вендора.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 22.03.2017 в 10:12.
За это сообщение автора поблагодарили: dn (6), belugin (3), gl00mie (3), ax_mct (10), mazzy (2), Stitch_MS (3).
Старый 22.03.2017, 11:57   #45  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Хочу поддержать sukhanchik. Когда-то давно писал о том что апгрейды ERP окупаются ТОЛЬКО если сам бизнес заказчика слишком изменился с момента внедрения.
А Микрософт как раз сейчас пытается продавать легкость апгрейда (крайне сомнительное преимущество с точки зрения клиента) в обмен на утрату контроля над приложением, утраты контроля за ключевыми бизнес-данными (в случае использования cloud), утраты контроля за будущими расходами (опять таки в случае cloud) и заметного увеличения стоимости внедрения (за счет более сложной и дорогой разработки и за счет гораздо более сложного исправления ошибок в production).
За это сообщение автора поблагодарили: ax_mct (10).
Старый 30.03.2017, 10:31   #46  
Predatore is offline
Predatore
Участник
 
163 / 17 (1) ++
Регистрация: 29.09.2010
Сейчас, только делать что-то рядом вклиниваясь на последней миле. Что мог бы сделать МС? Добавить самую малость ООП. Не обязательно внедрять всю парадигму целиком со всей её мощью и выразительностью. Достаточно реализовать хоть что-то отдалённо напоминающее наследование. Нужно поле 25 в таблице 17? Наследуйся и добавляй всё что душе угодно. Надо переопределить функцию из закрытого кодеюнита? Наследуйся и переопределяй на здоровье. Полиморфизм уже присутствует в зачаточном состоянии в виде переменных Variant, их ещё чуточку подкрутить, научить работать с родителями и наследниками и вообще в НАВе не будет не решаемых задач.
Ну а если всё это слишком сложно и кого-то сильно пугает. Можно слямзить такую штуку как partial. Она по сути своей элементарна как в понимании так и в реализации. Если в двух словах, то с помощью partial объект собирается из частей. На примере 17 таблицы, это может быть её закрытая часть, которую менять нельзя и сколько угодно открытых (каждый вендор может иметь свой кусочек с ограничением доступа для других вендоров), добавляющих к ней поля, функции, а начиная с 16 НАВика ещё и свойства. Когда же вы обращаетесь к ней в коде, вы видите цельную 17 таблицу, а то что она собрана из кусочков, это вас вообще не волнует.
Сделать можно много, главное захотеть.
P.S. Ещё бы очень хотелось поддержку если не классов, то хотя бы структур, но это я что-то совсем размечтался...

Последний раз редактировалось Predatore; 30.03.2017 в 10:35.
Старый 30.03.2017, 18:36   #47  
Morpheus is offline
Morpheus
Участник
Аватар для Morpheus
Соотечественники
 
602 / 164 (7) ++++++
Регистрация: 30.03.2005
Адрес: Київ-København-Düsseldorf
Цитата:
Сообщение от fed Посмотреть сообщение
А Микрософт как раз сейчас пытается продавать легкость апгрейда (крайне сомнительное преимущество с точки зрения клиента)...
Легкость обновлений нужна не клиентам, а Майкрософту, чтобы без ведома клиента устаналивать исправения еще до того, как клиент баги обнаружит.
Старый 30.03.2017, 21:59   #48  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,294 / 221 (10) ++++++
Регистрация: 11.01.2006
придумалась аналогия...
покупаем женщину (систему), способную по дефолту родить ребенка (собственно то, что нужно бизнесу).
процесс зачатия я опущу, не хочу в маркетинг углубляться, но процесс внутриутробного развития освещу подробно.
дите развивается не в маме, а в плаценте. по большому счету человеки те же яйцекладущие.
а как устроена плацента? это яйцо, миллиардами ниточек связанное с организмом матери.
так вот "разработка при закрытом коде" это как раз управление плацентой.
мы должны сделать огромную настроечную табличку, в которой включать и отключать собственные ниточки к организму матери. в самом организме наковырять дырочек, куда вонзаются ниточки (читаем, одной-двумя строками вызывать кастомизированную функциональность), сделать модуль управления плацентой (как обработать то что мы получили).
и в итоге в организме матери можно будет и почку поменять и сиськи увеличить стандартными средствами, а ребенок не должен пострадать при этом.
За это сообщение автора поблагодарили: mazzy (2).
Старый 30.03.2017, 23:03   #49  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Morpheus Посмотреть сообщение
Легкость обновлений нужна не клиентам, а Майкрософту, чтобы без ведома клиента устаналивать исправения еще до того, как клиент баги обнаружит.
Только это не ради обновлений, а ради сокращения срока поддержки продукта, чтобы им (MS) надо было поддерживать не зоопарк своих систем (2009, 2012 RTM, 2012 R2, 2012 R3, D365) со всеми их промежуточными внутренними KR, CU и.т.п.
А иметь одну версию D365 c коротким хвостом, который быстро сам подтягивается к голове (автоматические апгрейды). А кто не успел - тот опоздал (раз в 3 года топориком - хрясь)

Т.е. не смешивайте цель и средство.

Цитата:
Источник: https://community.dynamics.com/ax/b/...sibility-plans
==============
The Modern support policy provides three years of support for a release. Given this, overlayered code will continue to be supported in the Fall 2017 for three years.
Старый 31.03.2017, 10:23   #50  
Predatore is offline
Predatore
Участник
 
163 / 17 (1) ++
Регистрация: 29.09.2010
Цитата:
Сообщение от Logger Посмотреть сообщение
Только это не ради обновлений, а ради сокращения срока поддержки продукта, чтобы им (MS) надо было поддерживать не зоопарк своих систем (2009, 2012 RTM, 2012 R2, 2012 R3, D365) со всеми их промежуточными внутренними KR, CU и.т.п.
А иметь одну версию D365 c коротким хвостом, который быстро сам подтягивается к голове (автоматические апгрейды). А кто не успел - тот опоздал (раз в 3 года топориком - хрясь)

Т.е. не смешивайте цель и средство.
NAV 2009 уже давным давно не поддерживается, 2013 умрёт в следующем году.И что бы не произошло c NAV в будущем, это сильно вряд ли что-то изменит в этом плане. Тот же Office 2013 обновляется до Office 2016 даблкликом. И тем не менее поддержка Office 2013 заканчивается в следующем году.

Не путайте тёплое с мягким. Всё это нужно именно ради лёгких обновлений. Вернёмся к тому же Офису, что нужно для обновления? Купить лицензию или подписку. Последняя включает в себя все обновления на срок действия подписки. А дальше даже домохозяйка справится с обновлением. Всё, сделка завершена, считаем прибыль.
А что же в случае с NAV? Давайте самый печальный расклад рассмотрим, у клиента 2009 или что-то ещё более древнее. Что нужно для обновления? Всё та же лицензия с одной стороны, а с другой стороны: нуууу, вам нужно полное перевнедрение, которое вполне возможно выйдет ещё дороже чем внедрение. Как так? А вот так, мало того что системы сильно отличаются, так ещё и ваша кастомизация превратила систему в не поддерживаемого монстра.
Я бы медали из золота выдавал продавцам, которые бы смогли впарить обновление клиенту на таких условиях.

Главное - увеличить продажи, а никак не уменьшить срок поддержки, который всё равно не уменьшится.
Старый 31.03.2017, 10:48   #51  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Predatore Посмотреть сообщение
Главное - увеличить продажи, а никак не уменьшить срок поддержки, который всё равно не уменьшится.
Так вроде ж в ссылке выше английским по белому написано про 3 года поддержки. Т.е. уменьшится.
Старый 31.03.2017, 12:01   #52  
Predatore is offline
Predatore
Участник
 
163 / 17 (1) ++
Регистрация: 29.09.2010
Цитата:
Сообщение от Logger Посмотреть сообщение
Так вроде ж в ссылке выше английским по белому написано про 3 года поддержки. Т.е. уменьшится.
Ссылка мёртвая.
И даже если поддержку сократят вплоть до 1 года, всё равно. Упрощение обновлений в первую очередь нужно для продажи этих самых обновлений.
Старый 31.03.2017, 12:13   #53  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Predatore Посмотреть сообщение
Ссылка мёртвая.
И даже если поддержку сократят вплоть до 1 года, всё равно. Упрощение обновлений в первую очередь нужно для продажи этих самых обновлений.
Вот небитая:
https://community.dynamics.com/ax/b/...sibility-plans

Так теперь продаются не обновления, а подписка за пользование системой.
Старый 31.03.2017, 12:20   #54  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Predatore Посмотреть сообщение
Ссылка мёртвая.
И даже если поддержку сократят вплоть до 1 года, всё равно. Упрощение обновлений в первую очередь нужно для продажи этих самых обновлений.
Учитывая что они в облаке всех на подписку хотят перевести, вроде бы нету смысла особо напрягаться для именно продажи обновлений.
Кроме того, уже года 4 или 5 без покупки подписки на обновления невозможно покупать новых пользователей и новые модули. Так что я бы сказал - в Европе почти 100% заказчиков покупают подписку, но обновления не внедряют... Так что даже если on-premise версия будет продаваться по старой модели, реально ее без подписки использовать будет нельзя.
Старый 31.03.2017, 13:09   #55  
Predatore is offline
Predatore
Участник
 
163 / 17 (1) ++
Регистрация: 29.09.2010
А подписка - это и есть продажа обновлений, только размазанная во времени. И более того, если я оплачиваю подписку, в которой чёрным по белому сказано: "Вы будете получать бесплатно все обновления", я вполне резонно захочу их получать. И тут нам опять таки нужно обновление по принципу "далее, далее, готово". В России подписку вроде не берёт никто. Не знаю как сейчас, а несколько лет назад, пользователи и объекты как-то докупались и без подписки.
Вообще с этой подпиской и сокращением срока поддержки получается рискованная игра. Если МС сделают действительно лёгкие обновления, они выиграют в этой игре. Пока активна подписка, срок поддержки фактически не ограничен, при условии перехода на актуальные версии. Платить же за подписку, не переходить на новые версии и не получать поддержку... ну это звучит как фейл.
Старый 31.03.2017, 18:50   #56  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от Egil Посмотреть сообщение
Ну и наконец, не стоит забывать, что продукты Dynamics движутся семимильными шагами по дороге в облака.
Цитата:
Сообщение от macklakov Посмотреть сообщение
Мне кажется, не с того конца к проблеме подходим. Система изначально спроектирована исходя из предположения что код открыт.
ay, there's the rub

Изначально-то она спроектирована совсем другими людьми, исходя из концепции, что это будет некое средство разработки. А теперь "концепция изменилась" - бал правят люди, которые видят систему, как сервис (сиречь коммунальную услугу, по сути), за которую нужно платить абонентскую плату. И эта новая модель работает хорошо только тогда, когда все дружненько обновляются на новые версии с самым сертифицированным в мире функционалом. В идеале - вообще обновления инсталлируются производителем принудительно.

То есть - либо система, в идеале, должна плавно двигаться к состоянию "поставщик предоставляет средства разработки, а дальше разбирайтесь сами", либо к состоянию "пользователю разрешается поменять размер иконок и цвет фона на экране".
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 03.04.2017, 11:59   #57  
Pavel is offline
Pavel
SAP
SAP
 
2,760 / 239 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Не знаю как теперь у MS (те просто не интересно), а раньше у Damgaard/Navision можно было в шеснадцатеричном формате в текстовом редакторе кое-что поправить и любой слой сделать 'нужным'... отредактировать и обратно вернуть в 'неприкосновенное')))))
Старый 18.04.2017, 21:53   #58  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
По долгу службы дорабатываю решение на ASP.NET MVC, где куча кода закрыта в откомпилированных сборках, а для доработки, как раз и придумана возможность подписок, dependency injections на основе Unity и прочие гибкости которые предоставляет местный SDK.

Код большинства "закрытых" сборок предоставлен для ознакомления, и если бы его не было, пришлось бы повеситься. Текущий мой подход:
В класс-наследник, который расширяет какой-то метод, я копирую код из оригинала (чтобы не сломать стандартную логику обработки), и правлю его уже так, как нужно мне.

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

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

И все это счастье еще надо уметь готовить. Программировать по-новому, с ограниченными возможностями, тоже надо уметь. Это как сознательно себе выколоть глаза и пытаться заменить их другими органами чувств. Я думаю, программировать с помощью азбуки брайля тоже можно научится - врядли только это будет эффективно.
За это сообщение автора поблагодарили: Sancho (2), mazzy (2), gl00mie (2).
Старый 19.04.2017, 02:40   #59  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от artkashin Посмотреть сообщение
В класс-наследник, который расширяет какой-то метод, я копирую код из оригинала (чтобы не сломать стандартную логику обработки), и правлю его уже так, как нужно мне.
Вот кстати дискутировал на яммере по этому поводу. С точки зрения Микрософта копирование это совершенно валидный процесс.
Цитата:
Code duplication increases maintenance costs, but it at least doesn't break production.
т.е. в моем понимании вам к примеру недостаточно возможностей расширить какую-нибудь условную форму SalesTable, вы делаете свою. т.е. по сути любые ограничения extensions можно обойти с помощью дублирования объектов.
при этом клиент может собственно продолжать с легкостью ставить обновления от Микрософта, большие модификации в форме заказов не мешают этому.
Старый 19.04.2017, 03:53   #60  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от trud Посмотреть сообщение
Вот кстати дискутировал на яммере по этому поводу. С точки зрения Микрософта копирование это совершенно валидный процесс.

т.е. в моем понимании вам к примеру недостаточно возможностей расширить какую-нибудь условную форму SalesTable, вы делаете свою. т.е. по сути любые ограничения extensions можно обойти с помощью дублирования объектов.
при этом клиент может собственно продолжать с легкостью ставить обновления от Микрософта, большие модификации в форме заказов не мешают этому.
А как вы потом будите сводить их ? Скажем какой-то герой накопирует вам разного кода (вместе со стандартными багами), кастомизирует его, а потом добрый МС выпустит хотфикс в котором перепишит половину приватных методов которые вы скопировали и кастомизировали. Вы то об этом хотфиксе не узнаете, а когда узнаете надо будет как-то все это свести
 

Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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