05.12.2006, 13:24 | #21 |
Участник
|
Цитата:
Но похоже Satement of Direction мало кто читал, хотя ссылку даю уже не в первый раз http://forum.mazzy.ru/index.php?s=&sho...ost&p=19547 Итак, краткий пересказ своими словами по поводу среды разработки: 1. У Dynamics продуктов будет несколько волн изменений 2. Сейчас волна затрагивает функционал и ролеориентированный интерфейс 3. Планируется, что затем все средства разработки будут переведены на Visual Studio 3.1. При этом особенности языка каждой Dynamics-системы останутся. Так для Навижина останется C/AL 3.2. Майкрософт сильно озабочена тем, чтобы сделать переход на Visual Studio как можно менее болезненным. Поэтому будут конверторы, существующий код будет работать (Майкрософт говорит, что существующий код вообще менять не нужно будет. Я бы высказался осторожнее, что будут необходимы минимальные изменения) 4. Следующая версия Навижин 5.0 выходит в двух вариантах: традиционный и .net 4.1. Эти версии могут работать с одной базой одновременно 4.2. Средства разработки Навижин 5.0 еще не переведены на Visual Studio, но некоторые элементы уже вставлены. Так что рано или поздно нас ждет тотальный переход на VS со всеми преимуществами и недостатками этой среды разработки. |
|
05.12.2006, 13:24 | #22 |
Участник
|
Цитата:
И даже немного функционала в отдельной главе.
|
|
05.12.2006, 14:18 | #23 |
Участник
|
|
|
07.12.2006, 13:36 | #24 |
Участник
|
|
|
07.12.2006, 15:16 | #25 |
Участник
|
Это недостатки интерфейса пользователя, а не недостатки архитектуры. Т.к. автор сравнивает архитектуры систем, такое сравнение архитектур на таком поверхностном уровне никому не интересно. Оно не позволяет сделать выводы ни о быстродействии, ни о надежности, ни о масштабируемости, ни о чем в сравниваемых системах. Если бы рассматривались задачи и пути их решения в одной и другой системе и как это влияет на быстродействие, то другое дело.
Например есть более существенные недостатки Navision с точки зрения программирования. Несколько ситуаций, которые приходится обходить окольными путями: 1 Отсутствие аналога DISTINCT языка SQL для RecordSet. 2 Невозможно фильтровать записи на основе набора значений полученных в другом RecordSet. (Аналог подзапроса языка SQL). 3 Нельзя накладывать фильтры по условию “или”. Например Rec.SETFILTER(A,’1’); Rec.SETFILTER(B,’2’); Выберет записи в которых в поле A значение 1 И в В значение 2. А хотелось бы или в A=1 или B=2. И т.д. и т.п. А недостатки интерфейса вещь субъективная.
__________________
Должен остаться только один. |
|
07.12.2006, 15:39 | #26 |
Участник
|
Цитата:
Сообщение от NeNavision
1 Отсутствие аналога DISTINCT языка SQL для RecordSet.
2 Невозможно фильтровать записи на основе набора значений полученных в другом RecordSet. (Аналог подзапроса языка SQL). 3 Нельзя накладывать фильтры по условию “или”. Например Rec.SETFILTER(A,’1’); Rec.SETFILTER(B,’2’); Выберет записи в которых в поле A значение 1 И в В значение 2. А хотелось бы или в A=1 или B=2. И т.д. и т.п. А недостатки интерфейса вещь субъективная. Эти недостатки называются одной фразой: Navision не поддерживает SQL-язык запросов. Точка. Такой пункт я отметил. |
|
07.12.2006, 15:53 | #27 |
Участник
|
Нет, это так не называется!
Можно выполнять любые SQL запросы, получать данные и т.д. Или это не поддержка SQL? Я говорил о самом языке разработки, которым конкретно эти вещи сделать трудно.
__________________
Должен остаться только один. |
|
07.12.2006, 16:04 | #28 |
Участник
|
Цитата:
В 1С СКЛ-запросы - это именно штатный механизм языка. |
|
07.12.2006, 16:24 | #29 |
Участник
|
В прямом смысле. Работать с SQL запросами можно и ваше утверждение "Navision не поддерживает SQL-язык запросов. Точка." - ложно.
Перемененная Automation - это не штатный "механизм"? С другой стороны обработка в SQL очень редко нужна. Написали же как функционал без нее. Я же описал пример, когда код в навижен был бы меньше и работал быстрее, если бы были предусмотрены некоторые мелочи.
__________________
Должен остаться только один. |
|
07.12.2006, 16:59 | #30 |
Участник
|
Цитата:
Сообщение от NeNavision
В прямом смысле. Работать с SQL запросами можно и ваше утверждение "Navision не поддерживает SQL-язык запросов. Точка." - ложно.
Перемененная Automation - это не штатный "механизм"? С другой стороны обработка в SQL очень редко нужна. Написали же как функционал без нее. Я же описал пример, когда код в навижен был бы меньше и работал быстрее, если бы были предусмотрены некоторые мелочи. Нет, доступ к базе навижн через SQL - это не штатный механизм. Это не реализовано специальным типом в C\AL В 1С для этого есть внутренний тип Запрос. Кстати работает на СКЛ версии и на файловой версиии 1С, т.е. не привязан к движку MS SQL. Я понимаю, что прямые запросы можно юзать к любой базе, которая сделана на MS SQL, но это не штатный доступ. Или вы видели в типовом функционале Навижн прямые СКЛ запросы:? тотоже |
|
07.12.2006, 18:27 | #31 |
Участник
|
Гений1С. Как вы считаете, возможность в системе получить прямой доступ к данным на сервере и выполнить запрос к базе, используя штатные средства среды разработки не является ее минусом? Мне лично кажется, что разработчики системы тем самым как бы говорят - "Ребята, наша система может работать с миллионами строк, но .. кто знает, что будет у вас. На всякий случай вот вам механизм доступа к данным и делайте вы что хотите. Все, кто знает SQL". Ваше мнение?
|
|
07.12.2006, 18:46 | #32 |
Участник
|
Есть еще "громадные минусы".
Ассемблерные вставки нельзя делать и нет макросов. Как работать? Как писать шедевры? Где гибкость? Почему они так не любят разработчиков? Вот бы тогда раскрылась вся мощь среды разработки.
__________________
Должен остаться только один. |
|
08.12.2006, 13:05 | #33 |
Участник
|
Цитата:
Сообщение от romeo
Гений1С. Как вы считаете, возможность в системе получить прямой доступ к данным на сервере и выполнить запрос к базе, используя штатные средства среды разработки не является ее минусом? Мне лично кажется, что разработчики системы тем самым как бы говорят - "Ребята, наша система может работать с миллионами строк, но .. кто знает, что будет у вас. На всякий случай вот вам механизм доступа к данным и делайте вы что хотите. Все, кто знает SQL". Ваше мнение?
Блин, речь не об этом, как бы вам донести мысль. Доступ к СКЛ - это не штатный механизм навижн. Вы юзаете для этого Аутоматион. Вот в 1С 80 тоже можно прямой доступ к базе данных через ОЛЕ иметь и что с того. Ни в 80 ни в Навижн на уровне встроенного языка нет типа для прямого доступа к базе данных МС Скл - это и понятно, потому что базой данных и там и там может быть файловая версия и МС СКЛ. Просто в 1С 80 можно для обращения к таблицам использовать СКЛ-подобные запросы, а не только фильтрованные рекордсеты... как в Навижн(и клиппер, и аксесс и прочие старые СУБД). Даже в дельфи через ODBC можно юзать СКЛ запросы к таблицам, а не только рекордсеты. Так что здесь навижн очень устарело. Цитата:
Вместо ассемблерных вставок все сейчас используют ОЛЕ-аутоматион... |
|
23.04.2007, 13:15 | #34 |
Участник
|
Интересную позицию заняли некоторые госпада-наверно-программисты. Дескать, озвученные недостатки есть, но так как они нафик не нужны, то и недостатками их считать нельзя.
"Отсутствует что-то в среде разработки? Да нафик это нуна! Учись работать без этого! Приходится кодить в блокноте? Ерунда! Настоящий программист может кодить в чем угодно и как угодно! Хучь в блокноте простым текстом, хучь в двоичной системе ноликами и единицами! А кто не может, пусть переквалифицируется в управдомы." Отдельный респект "настоящему программисту" NeNavision, который может кодить в чем угодно и как угодно По теме. Согласен, Navision НЕ среда разработки приложений. Но кодить тем не менее приходится много (по крайней мере нам). Стандартной конфигурации не хватает никак и даже если сначала адаптировать ее под предприятие, со временем все равно появляется необходимость в новых формах, отчетах, в дополнительном функционале наконец. Поэтому в любой стОящей ERP-системе должна быть нормальная среда разработки. В связи с этим дико и нелогично на мой взгляд звучат утверждения типа "кодить неудобно но мы делаем это быстро, а это главное!". Это что за пример извращенной логики? Чем удобнее среда программирования, тем быстрее пишется код и тем быстрее решается задача. Этож очевидно. Привычка привычкой, но если для того, чтобы посмотреть, что делает конкретная функция в коде надо: 1. узнать, откуда она берется (начинатся камасутра) 2. открыть обжект десигнер 3. найти там таблицу/форму/отчет/кодюнит (выберите нужное) и открыть 4. найти нужную функцию (конец камасутры) ЭТОЖ КОШМАР! В делфи зажимаем ctrl и кликаем по имени функции. Среда сама откроет нужный модуль и переместит курсор на нужную функцию. Скорость в разборе кода больше в РАЗЫ! Это только один пример, приводить остальные смысла нет, так я свою т.з. высказал думаю понятно. Резюме. Не удобная среда разработки, очень неудобная. И привычки здесь ни причем. |
|
23.04.2007, 17:28 | #35 |
Участник
|
Я бы еще как-нибудь ограничил среду разработки. В таких системах, чем меньше свободы для творчества, тем лучше.
__________________
Должен остаться только один. |
|
24.04.2007, 05:33 | #36 |
Участник
|
Сушай, ненавизион, по моему ты просто стебаешся!
|
|
24.04.2007, 10:35 | #37 |
Участник
|
Я серьезно. Чем больше ограничений имеет программист, тем больше шансов, что задача будет решена в заданные сроки. Ограниченный набор способов реализации (свой подход к интерфейсу пользователя) и инструментов реализации (среда разработки) ограничивают полет больной фантазии клиентов и программистов. Насколько возможно выталкивает подход к решению проблемы из области программирования.
p.s. Делать ту же подсветку кода в редакторе программисту miсrosoft максимум день. Почему-то не делают. Наверное, потому что совершенствовать можно бесконечно, а денег на этом не заработаешь.
__________________
Должен остаться только один. |
|
24.04.2007, 12:58 | #38 |
NavAx
|
Полностью поддерживаю
__________________
"Моей лошадке ядрышком полмордочки снесло..." А.В.Суворов, письма к дочери |
|
24.04.2007, 13:19 | #39 |
Участник
|
Хм... Интересно, кроме меня утруждает ли себя еще кто нибудь аргументацией своего мнения или все считают, что его достаточно высказать а остальное сделает авторитет?
Цитата:
Ладно, короче из этой темы я руки умываю, а то одному аргументы приводить не интересно. Какаято односторонняя дискуссия получается... з.ы. Чем больше возможности для творчества, тем лучше |
|
24.04.2007, 13:38 | #40 |
Участник
|
Цитата:
Да? Borland неплохо зарабатывает.
А VS медленно, но верно совершенствуется, кстати подождите годик - два navision будет на VS.
__________________
Должен остаться только один. |
|