|
05.12.2006, 13:16 | #1 |
Участник
|
Цитата:
Видите ли есть еще соображения комфорта.[
Главный вопрос: Сколько стоит это сделать по времени и по деньгам? Остальное - лирика.
__________________
Должен остаться только один. |
|
05.12.2006, 13:18 | #2 |
Участник
|
Цитата:
Вот вы бы отказались от подсветки синтаксиса?
Цитата:
Вообще программисты обычно не мазохисты.
|
|
05.12.2006, 13:24 | #3 |
Участник
|
Цитата:
И даже немного функционала в отдельной главе.
|
|
07.12.2006, 13:36 | #4 |
Участник
|
|
|
07.12.2006, 15:16 | #5 |
Участник
|
Это недостатки интерфейса пользователя, а не недостатки архитектуры. Т.к. автор сравнивает архитектуры систем, такое сравнение архитектур на таком поверхностном уровне никому не интересно. Оно не позволяет сделать выводы ни о быстродействии, ни о надежности, ни о масштабируемости, ни о чем в сравниваемых системах. Если бы рассматривались задачи и пути их решения в одной и другой системе и как это влияет на быстродействие, то другое дело.
Например есть более существенные недостатки 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 | #6 |
Участник
|
Цитата:
Сообщение от 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 | #7 |
Участник
|
Нет, это так не называется!
Можно выполнять любые SQL запросы, получать данные и т.д. Или это не поддержка SQL? Я говорил о самом языке разработки, которым конкретно эти вещи сделать трудно.
__________________
Должен остаться только один. |
|
07.12.2006, 16:04 | #8 |
Участник
|
Цитата:
В 1С СКЛ-запросы - это именно штатный механизм языка. |
|
07.12.2006, 16:24 | #9 |
Участник
|
В прямом смысле. Работать с SQL запросами можно и ваше утверждение "Navision не поддерживает SQL-язык запросов. Точка." - ложно.
Перемененная Automation - это не штатный "механизм"? С другой стороны обработка в SQL очень редко нужна. Написали же как функционал без нее. Я же описал пример, когда код в навижен был бы меньше и работал быстрее, если бы были предусмотрены некоторые мелочи.
__________________
Должен остаться только один. |
|
07.12.2006, 16:59 | #10 |
Участник
|
Цитата:
Сообщение от NeNavision
В прямом смысле. Работать с SQL запросами можно и ваше утверждение "Navision не поддерживает SQL-язык запросов. Точка." - ложно.
Перемененная Automation - это не штатный "механизм"? С другой стороны обработка в SQL очень редко нужна. Написали же как функционал без нее. Я же описал пример, когда код в навижен был бы меньше и работал быстрее, если бы были предусмотрены некоторые мелочи. Нет, доступ к базе навижн через SQL - это не штатный механизм. Это не реализовано специальным типом в C\AL В 1С для этого есть внутренний тип Запрос. Кстати работает на СКЛ версии и на файловой версиии 1С, т.е. не привязан к движку MS SQL. Я понимаю, что прямые запросы можно юзать к любой базе, которая сделана на MS SQL, но это не штатный доступ. Или вы видели в типовом функционале Навижн прямые СКЛ запросы:? тотоже |
|
07.12.2006, 18:27 | #11 |
Участник
|
Гений1С. Как вы считаете, возможность в системе получить прямой доступ к данным на сервере и выполнить запрос к базе, используя штатные средства среды разработки не является ее минусом? Мне лично кажется, что разработчики системы тем самым как бы говорят - "Ребята, наша система может работать с миллионами строк, но .. кто знает, что будет у вас. На всякий случай вот вам механизм доступа к данным и делайте вы что хотите. Все, кто знает SQL". Ваше мнение?
|
|
08.12.2006, 13:05 | #12 |
Участник
|
Цитата:
Сообщение от romeo
Гений1С. Как вы считаете, возможность в системе получить прямой доступ к данным на сервере и выполнить запрос к базе, используя штатные средства среды разработки не является ее минусом? Мне лично кажется, что разработчики системы тем самым как бы говорят - "Ребята, наша система может работать с миллионами строк, но .. кто знает, что будет у вас. На всякий случай вот вам механизм доступа к данным и делайте вы что хотите. Все, кто знает SQL". Ваше мнение?
Блин, речь не об этом, как бы вам донести мысль. Доступ к СКЛ - это не штатный механизм навижн. Вы юзаете для этого Аутоматион. Вот в 1С 80 тоже можно прямой доступ к базе данных через ОЛЕ иметь и что с того. Ни в 80 ни в Навижн на уровне встроенного языка нет типа для прямого доступа к базе данных МС Скл - это и понятно, потому что базой данных и там и там может быть файловая версия и МС СКЛ. Просто в 1С 80 можно для обращения к таблицам использовать СКЛ-подобные запросы, а не только фильтрованные рекордсеты... как в Навижн(и клиппер, и аксесс и прочие старые СУБД). Даже в дельфи через ODBC можно юзать СКЛ запросы к таблицам, а не только рекордсеты. Так что здесь навижн очень устарело. Цитата:
Вместо ассемблерных вставок все сейчас используют ОЛЕ-аутоматион... |
|
07.12.2006, 18:46 | #13 |
Участник
|
Есть еще "громадные минусы".
Ассемблерные вставки нельзя делать и нет макросов. Как работать? Как писать шедевры? Где гибкость? Почему они так не любят разработчиков? Вот бы тогда раскрылась вся мощь среды разработки.
__________________
Должен остаться только один. |
|
23.04.2007, 13:15 | #14 |
Участник
|
Интересную позицию заняли некоторые госпада-наверно-программисты. Дескать, озвученные недостатки есть, но так как они нафик не нужны, то и недостатками их считать нельзя.
"Отсутствует что-то в среде разработки? Да нафик это нуна! Учись работать без этого! Приходится кодить в блокноте? Ерунда! Настоящий программист может кодить в чем угодно и как угодно! Хучь в блокноте простым текстом, хучь в двоичной системе ноликами и единицами! А кто не может, пусть переквалифицируется в управдомы." Отдельный респект "настоящему программисту" NeNavision, который может кодить в чем угодно и как угодно По теме. Согласен, Navision НЕ среда разработки приложений. Но кодить тем не менее приходится много (по крайней мере нам). Стандартной конфигурации не хватает никак и даже если сначала адаптировать ее под предприятие, со временем все равно появляется необходимость в новых формах, отчетах, в дополнительном функционале наконец. Поэтому в любой стОящей ERP-системе должна быть нормальная среда разработки. В связи с этим дико и нелогично на мой взгляд звучат утверждения типа "кодить неудобно но мы делаем это быстро, а это главное!". Это что за пример извращенной логики? Чем удобнее среда программирования, тем быстрее пишется код и тем быстрее решается задача. Этож очевидно. Привычка привычкой, но если для того, чтобы посмотреть, что делает конкретная функция в коде надо: 1. узнать, откуда она берется (начинатся камасутра) 2. открыть обжект десигнер 3. найти там таблицу/форму/отчет/кодюнит (выберите нужное) и открыть 4. найти нужную функцию (конец камасутры) ЭТОЖ КОШМАР! В делфи зажимаем ctrl и кликаем по имени функции. Среда сама откроет нужный модуль и переместит курсор на нужную функцию. Скорость в разборе кода больше в РАЗЫ! Это только один пример, приводить остальные смысла нет, так я свою т.з. высказал думаю понятно. Резюме. Не удобная среда разработки, очень неудобная. И привычки здесь ни причем. |
|
23.04.2007, 17:28 | #15 |
Участник
|
Я бы еще как-нибудь ограничил среду разработки. В таких системах, чем меньше свободы для творчества, тем лучше.
__________________
Должен остаться только один. |
|
24.04.2007, 12:58 | #16 |
NavAx
|
Полностью поддерживаю
__________________
"Моей лошадке ядрышком полмордочки снесло..." А.В.Суворов, письма к дочери |
|
24.04.2007, 05:33 | #17 |
Участник
|
Сушай, ненавизион, по моему ты просто стебаешся!
|
|
24.04.2007, 10:35 | #18 |
Участник
|
Я серьезно. Чем больше ограничений имеет программист, тем больше шансов, что задача будет решена в заданные сроки. Ограниченный набор способов реализации (свой подход к интерфейсу пользователя) и инструментов реализации (среда разработки) ограничивают полет больной фантазии клиентов и программистов. Насколько возможно выталкивает подход к решению проблемы из области программирования.
p.s. Делать ту же подсветку кода в редакторе программисту miсrosoft максимум день. Почему-то не делают. Наверное, потому что совершенствовать можно бесконечно, а денег на этом не заработаешь.
__________________
Должен остаться только один. |
|
24.04.2007, 13:19 | #19 |
Участник
|
Хм... Интересно, кроме меня утруждает ли себя еще кто нибудь аргументацией своего мнения или все считают, что его достаточно высказать а остальное сделает авторитет?
Цитата:
Ладно, короче из этой темы я руки умываю, а то одному аргументы приводить не интересно. Какаято односторонняя дискуссия получается... з.ы. Чем больше возможности для творчества, тем лучше |
|
24.04.2007, 13:38 | #20 |
Участник
|
Цитата:
Да? Borland неплохо зарабатывает.
А VS медленно, но верно совершенствуется, кстати подождите годик - два navision будет на VS.
__________________
Должен остаться только один. |
|