|
![]() |
#1 |
Участник
|
Цитата:
но ты совершенно правильно заметил, что только у "построенного с помощью SysOperation". а у остальных, по твоему мнению, нет такой возможности. в результате у разработчика не один "плохой" набор RunBase а два совершенно разных. в результате нужно не только знать оба, но и знать как заставить их работать совместно. с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась. а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности. и так во многих местах аксапты за редким исключением типа (subledger, dimension). вводятся новые инструменты-фреймворки. пусть они все замечательные. но старые то не выводятся. |
|
![]() |
#2 |
Участник
|
Цитата:
Цитата:
в результате у разработчика не один "плохой" набор RunBase
а два совершенно разных. в результате нужно не только знать оба, но и знать как заставить их работать совместно. В случае RunBase нет почти никакого общего способа заставить работать два RunBase вместе: - Как использовать бизнеслогику одного из другого надо разбираться с каждым классом (у SysOP есть API который называется стандартно и представляет просто метод с параметром) - UI совместно не используешь (несколько контрактов SysOP можно скомбинировать в один диалог) - Только pack можно использовать из другого pack (с runbase надо разбираться - они паковку не вынесли отдельно) Цитата:
с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась.
а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности. Цитата:
и так во многих местах аксапты за редким исключением типа (subledger, dimension).
вводятся новые инструменты-фреймворки. пусть они все замечательные. но старые то не выводятся. |
|
![]() |
#3 |
Участник
|
1. не надо демагогии и слова ВСЕ ))) речь идет о SysOperation, которая должна заменить RunBase.
2. "Реально никто [в МС] не заморачивается" - это и есть причина Оver-engineering с точки зрения остальных разработчиков. Тут, наверное, мне стоит объяснить остальным участникам, что фраза Макса "не заморачивается [API]" вовсе не говорит о том, что разработчики в МС не заморачиваются ничем. В МС самая замороченная процедура приемки кода изо всех что я видел. Поэтому заморачиваться разработчику в МС приходится очень много чем. Просто критерии важности в МС сильно отличаются от критериев важности на проектах заказчиков и партнеров. Следовательно заморачиваются в МС очень другими вещами, чем на проектах (собственно об этом я и говорил выше). Цитата:
пример - хелперы в процедуре закрытия склада. Цитата:
Цитата:
можно я не буду дальше комментировать? собственно одно - просто критерии другие. другие выводы. уверен, что поставь любого разработчика (включая и меня) в условия, в которых живет Макс, дай задачи, которые решает Макс, и система критериев будет такой же. Цитата:
но для определенности, можешь привести пример? Ой, все! вот только не надо как 1Сники валить на другую систему. Типа "у нас гавно, а вот там еще хуже". фиг с ними, с сапами, давай в своей системе разбираться/прибираться. |
|
Теги |
sysoperation framework |
|
|